Systems and methods for medical device monitoring

ABSTRACT

In an example, a system includes a computing device storing instructions executable to: receive an insight defined by a user, the insight dictating that a notification be output when a condition and a scope of the condition are met, the condition and the scope defined by the user; receive real-time medical device data determined from output from a plurality of medical devices monitoring a plurality of patients; determine if a set of values of one or more patient monitoring parameters of the medical device data meet the condition and the scope, and if so, output the notification for display on a display operably coupled to a first care provider device associated with the user; and responsive to a request from the user, adjust a privacy setting of the insight to allow the insight to be distributed to one or more additional care provider devices associated with other users.

PRIORITY

This application is a continuation of U.S. patent application Ser. No.16/557,930, filed on Aug. 30, 2019, which is incorporated herein byreference in its entirety.

FIELD

Embodiments of the subject matter disclosed herein relate to medicaldevice monitoring, and more specifically to medical device monitoringduring perioperative care.

BACKGROUND

Certain medical procedures, such as surgery, may require varioussub-procedures to be performed to prep the patient for surgery, maintainthe patient in a certain condition during surgery (e.g., anesthetized),and help the patient recover after surgery. Such sub-procedures that areperformed in support of a main procedure may be referred to asperioperative care. Perioperative care of patients in a hospital orother medical facility may include multiple patient monitoring devicesmonitoring multiple patients. Thus, to ensure a rapid response should apatient's condition deteriorate, near-continuous monitoring of theoutput from the multiple monitoring devices may be necessary. Further,coordination of patient care among all the care providers may becomplicated or time-consuming, further stretching care providerresources. Additionally, the presentation of patient medical informationto the care providers may require multiple time-consuming and cumbersomerequests or searches for information.

BRIEF DESCRIPTION

In one embodiment, a system includes a computing device storinginstructions executable to: receive an insight defined by a user, theinsight dictating that a notification be output when a condition and ascope of the condition are met, the condition and the scope defined bythe user; receive real-time medical device data determined from outputfrom a plurality of medical devices monitoring a plurality of patients;determine if a set of values of one or more patient monitoringparameters of the medical device data meet the condition and the scope,and if so, output the notification for display on a display operablycoupled to a first care provider device associated with the user; andresponsive to a request from the user, adjust a privacy setting of theinsight to allow the insight to be distributed to one or more additionalcare provider devices associated with other users.

It should be understood that the brief description above is provided tointroduce in simplified form a selection of concepts that are furtherdescribed in the detailed description. It is not meant to identify keyor essential features of the claimed subject matter, the scope of whichis defined uniquely by the claims that follow the detailed description.Furthermore, the claimed subject matter is not limited toimplementations that solve any disadvantages noted above or in any partof this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawing(s) will be provided by the Office upon request and paymentof the necessary fee.

The present disclosure will be better understood from reading thefollowing description of non-limiting embodiments, with reference to theattached drawings, wherein below:

FIGS. 1A and 1B schematically show an example system for perioperativecare and supervision including a supervisory application.

FIGS. 2-5 and 28 show an example display device displaying various viewsof a single-patient graphical user interface generated via thesupervisory application.

FIGS. 6 and 7 show the display device displaying various views of atrends graphical user interface generated via the supervisoryapplication.

FIGS. 8-10 show the display device displaying various notificationsoutput as part of the single-patient graphical user interface generatedvia the supervisory application.

FIGS. 11-15 show the display device displaying various views of amulti-patient graphical user interface generated via the supervisoryapplication.

FIGS. 16-20 show the display device displaying various views of aninsight graphical user interface generated via the supervisoryapplication.

FIGS. 21-23 show an example display device displaying various views ofan in-room graphical user interface generated via the supervisoryapplication.

FIG. 24 is a flow chart illustrating an example method for displayingsupervising graphical user interfaces generated via the supervisoryapplication.

FIG. 25 is a flow chart illustrating an example method for generatingand outputting notifications via the supervisory application.

FIG. 26 is a flow chart illustrating an example method for displayingin-room graphical user interfaces generated via the supervisoryapplication.

FIG. 27 is a flow chart illustrating an example method for a supervisoryapplication.

FIG. 29 shows an example display device displaying a new insights viewgenerated via the supervisory application.

DETAILED DESCRIPTION

Embodiments of systems and methods as disclosed herein operate tofacilitate perioperative care for a plurality of patients, andsupervision of a plurality of care providers attending to the pluralityof patients. To facilitate the perioperative care and supervisiondescribed herein, the systems and methods as disclosed herein collectand process a wide variety of medical device data. Medical device dataincludes physiological data (also referred to as patient monitoringdata) that is acquired from a patient by a medical device and machinedata collected internally from the medical device itself. Machine datamay include alarms, device status, settings, messages, and measuredoperational data. Machine data may further include settings and valuesthat represent specific actions taken with the medical device forexample, in response to automated controls or due to clinician inputs.For example, in an anesthesia delivery machine, this may include changesto oxygen and/or anesthetic agent concentrations. The machine data mayfurther include clinical and/or technical alarms initiated by themedical device or device diagnostic information. Still further examplesof the machine data include proactive or predictive service alerts fromthe medical device, maintenance checkout information, and/or processorclock cycle signals or power signals or other operational signals fromvarious components of the medical device indicative that the medicaldevice is turned on, in use, in operation, held in a stand by condition,or turned off.

The medical device data can be collected in time series format asprovided from the medical devices themselves. As used herein, the timeseries format of the medical device data can include waveforms, binarydata, numeric data, and/or textual data in a time series format.Embodiments of the systems and methods as disclosed herein receive themedical device data from the medical devices at a frequency similar tothe frequency at which it is produced by the medical device. Inembodiments, this increased velocity of the received data and themonitoring and analysis of medical device machine data can enableimproved monitoring systems and methods as disclosed herein. Asdescribed in further detail herein, embodiments of systems and methodssupport high speed data ingestion, enrichment, normalization, and datacuration of the medical device data. The medical device data can undergoreal time analysis and further enrichment of the data with eventdetection and notation. While all of the medical device data can besaved for retrospective and automated machine learning and analysis,event detection and notation can be used to create further exemplaryfiles of medical device data stemming from particular events orconditions which can be used as exemplary or case study data for furtheranalysis.

The medical device data may be supplied to one or more care providers,such as a supervising anesthesiologist, nurse anesthesiologists, andother care providers. In particular, the medical device data may besupplied to the supervising anesthesiologist or other supervising careprovider via a supervisory application that facilitates presentation ofthe medical device data in real-time or near real-time via one or moregraphical user interfaces that may be displayed on a device of thesupervising care provider, such as a mobile device (e.g., smart phone,tablet, wearable). The supervisory application may facilitate display ofmedical device data, including physiological data and medical devicesetting/parameter data, for a plurality of patients and for a pluralityof different patient monitoring parameters to the supervising careprovider. The displayed medical device data for the plurality ofpatients may be displayed simultaneously in a multi-patient graphicaluser interface (GUI), which may allow the supervising care provider toeasily monitor patient status for each patient, even if the careprovider is located away from the patient(s). When additionalinformation for a specific patient is desired, the supervisoryapplication may generate a single-patient GUI that provides moredetailed medical device data for the patient.

The supervisory application may also monitor patient status, via themedical device data, and may output various notifications, such asalarms, when patient status changes or a specified patient monitoringparameter or combination of parameters (such as blood oxygenation)reaches a predefined condition relative to a threshold (e.g., dropsbelow a threshold) or changes over time. The supervisory application mayalso facilitate communication between the supervising care provider andone or more subordinate care providers that may be in a room with apatient while the supervising care provider is located in a differentroom or area of the medical facility. For example, a subordinate careprovider may send a request, via an in-room GUI of the supervisoryapplication that is executed on a device of the subordinate careprovider, for a consultation from the supervising care provider, whichmay be received by the supervising care provider's device and output tothe supervising care provider via a GUI of the supervisory application.The in-room GUI may also facilitate text or voice messaging between thesubordinate care provider and the supervising care provider.

The supervisory application may also generate a trends GUI that may beoutput on the supervising care provider's device. Via the trends GUI,the supervising care provider may assess, for a plurality of selectedpatient monitoring parameters, change in medical device data over time.The trend for each selected patient monitoring parameter may bedisplayed simultaneously in a time-aligned fashion. Further, a relativechange in each patient monitoring parameter over a specified timeduration may be determined and displayed in response to a single userinput.

The various GUIs and functions of the supervisory application describedabove may allow for a single supervising care provider to simultaneouslymonitor multiple patients during respective medical procedures, such assurgery. While each patient may be attended to by multiple careproviders during the medical procedure, such as one or more surgeons,nurses, medical technicians, etc., certain supervising care providers,such as anesthesiologists, may attend to multiple patients at once andmay oversee a plurality of subordinate care providers, such as nurseanesthesiologists. As the number of subordinate care providers increasesrelative to the number of supervising care providers, and as medicalprocedures become more complex, the need for a supervising care providerto be able to monitor patients and oversee subordinate care providersremotely has increased. For example, a supervising anesthesiologist maybe scheduled to initiate and monitor an induction phase of anesthesiafor a patient, which may demand the supervising anesthesiologist be inthe operating room with the patient during that time. However, thesupervising anesthesiologist may also be attending to six other patientsthat are in the maintenance phase of anesthesia, with each of the sixother patients being monitored by an in-room nurse anesthesiologist. Ifan event were to occur to one of the six other patients that demandedthe care of the supervising anesthesiologist, there may be a delay fromwhen the supervising anesthesiologist is notified of the event to whenthe supervising anesthesiologist could actually arrive to care for thepatient. However, via the supervisory application described herein, thesupervising care provider may be able to monitor patient status for allpatients from any location, and may be able to adjust medical therapydevice settings and/or instruct subordinate care providers from afar. Indoing so, patient care may be improved.

The supervisory application may facilitate the display of real-timemedical device data obtained and/or determined from a plurality ofmedical devices monitoring a plurality of patients. The real-timemedical device data may be displayed via various graphical userinterfaces (GUIs). As an example, a single-patient GUI may be displayedon a care provider device (e.g., mobile phone, tablet, and/or wearable).Via the single-patient GUI, real-time medical device data for a patientmay be displayed via a plurality of patient monitoring parameter tiles.The plurality of patient monitoring parameter tiles may be scalable,modular, and customizable by the user and/or by the supervisoryapplication to allow for easy customizability, and ease of adding newpatient monitoring parameters/medical device data in the future. Forexample, a user of the supervisory application (e.g., a care providersuch as an anesthesiologist) may create a set of rules or an algorithm(where the rules or algorithm may be referred to as an insight) that maybe executed using the real-time medical device data to determine aresult (e.g., a determination of procedure phase, a prediction ofpatient state, a recommended course of action, etc.) or a notificationof patient status. When the user selects to apply the insight, theresult of the insight may be displayed as a tile on the patient-specificGUI going forward, and the other patient monitoring parameter tiles onthe patient-specific GUI may be adjusted (e.g., moved, resized, scaled,and so forth) to accommodate the new insight result tile. As anotherexample, the user may select to include a real time video feed from thepatient's room as a tile in the single-patient GUI (larger variety),which may require a relatively large sized tile. The remaining tiles maybe rearranged (whether automatically or in response to the user) toaccommodate the larger tile.

FIGS. 1A and 1B depict an exemplary embodiment of a system 10 forperioperative care and supervision. Referring first to FIG. 1A, system10 includes a medical device data (MDD) processing system 12. The MDDprocessing system 12 can be implemented in a variety of hardware and/orsoftware implementations and it should be noted that suchimplementations are not considered to be limiting. For example, it iscontemplated that any or all of the MDD processing system 12 may beembodied exclusively in hardware, exclusively in software, exclusivelyin firmware or in any combination of hardware, software, and/orfirmware. While the following describes exemplary methods and systems,the examples provided herein are not the only way to implement suchmethods and systems.

In embodiments wherein any of the claims are read to cover an entirelysoftware and/or firmware implementation, in any embodiment, at least oneof the elements is hereby expressly defined to include a tangible andnon-transient computer readable medium. As used herein, the termtangible computer readable medium is expressly defined to include anytype of computer readable storage and to exclude propagating signals.Additionally or alternatively, the example methods and systems may beimplemented using coded instruction (e.g., computer readableinstructions) stored on a non-transitory computer readable medium suchas a flash memory, a read-only memory (ROM) a random-access memory(RAM), a cache, or any other storage media in which information isstored for any duration (e.g. for extended period time periods,permanently, brief instances, for temporarily buffering, and/or forcaching of the information). As used herein, the term non-transitorycomputer readable medium is expressly defined to include any type ofcomputer readable medium and to exclude propagating signals.

In exemplary and non-limiting embodiments of the medical device dataprocessing system 12, the system 12 is implemented by one or morenetworked processors or computing devices. Processing system 12 may beimplemented in a cloud computing platform and/or infrastructure. Memoryand processors as referred to herein can be standalone or integrallyconstructed as part of various programmable devices, including forexample, computers or servers. Computer memory of computer readablestorage mediums as referenced herein may include volatile andnon-volatile or removable and non-removable media for a storage ofelectronic-formatted information such as computer readable programinstructions or modules of computer readable program instructions, data,etc. that may be stand-alone or as part of a computing device. Examplesof computer memory may include, but are not limited to RAM, ROM, EEPROM,flash memory, CD-ROM, DVD-ROM or other optical storage, magneticcassettes, magnetic tape, magnetic disc, or other magnetic storagedevices, or any other medium which can be used to store the desiredelectronic format of information and which can be accessed by theprocessor or processors or at least a portion of a computing device.

The MDD processing system 12 is communicatively connected to at leastone hospital network 14. Such communicative connections as well as thehospital network itself may include, but are not limited to, a wide areanetwork (WAN); a local area network (LAN); the internet; wired orwireless (e.g. optical, Bluetooth, radio frequency (RF) network; acloud-based computer infrastructure of computers, routers, servers,gateways, etc.; or any combination thereof associated therewith thatallows the system or portions thereof to communicate with one or morecomputing devices.

The hospital network 14 may exemplarily be a network associated with aportion of a hospital, for example a surgery unit or department of ahospital, or may be more broadly located across medical devices of anentire hospital. It further will be recognized that while someembodiments and implementations of the systems and methods as disclosedherein may seek to operate on a single hospital or unit of a hospital,still other embodiments may connect a plurality of hospital networks,including hospitals currently owned or operated or otherwise affiliatedwith one another. In still further embodiments, while individualhospitals or groups of hospitals may use the MDD processing system 12,the MDD processing system 12 may receive and process information from aplurality of hospital networks including those unaffiliated with oneanother at the same time.

As depicted in FIG. 1A, the hospital network 14 includes a plurality ofmedical devices 16. The medical devices 16 may include physiologicalmonitoring devices 16 a as well as patient therapy devices 16 b.Physiological monitoring devices 16 a may include, but are not limitedto, heart rate monitors, blood pressure oxygenation monitors,respiration monitors, ECG monitors, EEG monitors, or EMG monitors. Anexemplary embodiment of an anesthesia delivery machine will be used fordiscussion purposes as the medical device, and more specifically as thepatient therapy device 16 b, although it will be recognized by a personof ordinary skill in the art that other devices, including but notlimited to patient respiratory assistance devices or dialysis machines,may be further non-limiting examples of patient therapy devices.However, it will be recognized that therapy devices may also includecapabilities to not only deliver patient therapy, but also to measurephysiological parameters of a patient. For example, embodiments ofanesthesia delivery machines may include gas analysis modules operableto measure gas concentrations expired by the patient. In someembodiments, imaging devices, including but not limited to X-ray, CT,MRI, and ultrasound devices, may be examples of medical devices 16 ascontemplated within the present disclosure. Still further examples ofmedical devices may include video and/or audio recording devices.

In an exemplary embodiment, a limited version of the MDD processingsystem 12 as described herein may be implemented locally, for example asan anesthesia delivery management system 18. In such an embodiment, theanesthesia delivery management system 18 may operate to collect medicaldevice data from a plurality of anesthesia delivery machines 16 b interalia to monitor anesthesia agent use between anesthesia deliverymachines and across procedures performed by the anesthesia deliverymachines in an effort to visualize anesthetic agent consumption and useas well as to quantify, monitor, and evaluate trends across all of theanesthesia delivery machines in the hospital or surgical unit.

The medical devices 16 may be communicatively connected to one or moreedge devices, such as edge device 20. Edge device 20 may exemplarily bean edge processing device, cloud processing device, or internet gateway.The edge device 20 may include an internet of things (IOT) gateway whichfacilitates a secure communications link between the medical devices 16at the hospital network 14 with the servers, processors, and computerreadable media implementing the MDD processing system 12. In exemplaryembodiments, the edge device 20 may communicate directly with one ormore of the medical devices 16, or may communicate with the medicaldevices 16 through an intermediate network, for example, the anesthesiadelivery management system 18 or another medical device data system ornetwork.

The edge device 20 receives the medical device data as time series datafor any of the medical device data available from the medical devices.As noted above, the data streams of medical device data (e.g., machinedata, monitored patient physiological parameter data) are available intime series format as acquired from the medical devices and may include,but are not limited to time series information of alarms, device status,device settings, messages, and measured data. In embodiments, themedical devices may be equipped with sensors that improve theself-awareness of the medical device, e.g. sensors that monitor thefunction, inputs and/or outputs of various components of the medicaldevice itself. Many such sensors are already incorporated into medicaldevices such as to measure compressor speeds and/or cycle times,internal pressures, voltages, clock speeds, or temperatures, or othersensors as will be recognized by a person of ordinary skill in the artor as disclosed in further detail herein.

The edge device 20 encrypts the time series formatted data and theencrypted data is transmitted using wired and/or wireless communicationtechniques for encrypted data to the server, processors, and datastorage carrying out the MDD processing system 12. The edge device 20continuously transmits de-identified medical device data in time seriesformat over an encrypted communication channel to a high speed dataingestion module 22 of the MDD processing system 12. While the exemplaryembodiment described herein may reference de-identified data, it will berecognized that other embodiments may use patient-identified data withappropriate considerations taken for handling patient data. The highspeed data ingestion module 22 takes in the real time streams of medicaldevice data. The data ingestion can be performed in an automated fashionand can preprocess the received streams of real time data in the timeseries for later processing by the MDD processing system 12. The highspeed ingestion module 22 can receive concurrent data streams frommultiple connected devices across multiple sites at a high incomingvelocity, for example at or near the frequency at which medical devicescan output data. In exemplary embodiments the high speed ingestionmodule 22 is scalable to continue to ingest increased bandwidth ofmedical device data without significant decrease in ingestion speeds.

The high speed ingestion module 22 takes the time series medical devicedata from the medical devices of one or more hospital networks andformats it for further processing by a data quality management module24. In exemplary and non-limiting embodiments, the high speed injectionmodule 22 supports open standard such as ASTMF 2761 or integratedclinical environmental (ICE). The data quality management module 24 maynormalize, enrich, and tag the data streams without negatively impactingdata latency. In a healthcare environment, a variety of healthcareinformation products and/or systems may be used to provide medicalservices, collect medical data, conduct medical exams, etc. However,many healthcare information systems operate using various messagingstandards (e.g., Health Level 7 International (HL7 V2.x/v3), ClinicalDocument Architecture/Continuity Of Care Document (CDA/CCD), AmericanSociety for Testing Materials (ASTM), Digital Imaging and Communicationsin Medicine (DICOM), etc.)) and various standards and/or protocols(e.g., cross-enterprise document sharing (XDS.A/B) cross-enterprisedocument media interchange (XDM) cross-enterprise document reliableinterchange (XDR), patient identifier cross-referencing/patientdemographics query (PIX/PDQ) patient administration management (PAM),query for existing data (QED), national counsel for prescription drugprograms (NCPDP), etc.)) that make system integration and/orcommunication more difficult. Thus, normalization may includereformatting of medical data to a consistent or compatible format foruse within the MDD processing system 12. In an exemplary embodiment, themedical device data may be normalized into the ISO/IEEE 11073-10101nomenclature and its extensions. In a still further exemplaryembodiment, the data quality management module 24 can normalize thestreams of incoming time series data by converting units of measure. Thedata quality management module 24 can further operate to identify andtag various types of medical device data, locations from which themedical device data was received, or time series data streamsoriginating from the same medical device. These tags can be used asfurther detailed herein to identify and analyze groups of streams oftime series data.

In an exemplary embodiment, the data quality management module 24normalizes the received incoming data by transforming and/or translatingthe clinical data streamed from the source healthcare system or deviceinto a canonical data model with associated metadata. The processedmedical device data is stored in a data lake 26 which is exemplarilyimplemented in computer readable storage embodying capability to storeterabytes of data. The data lake 26 is a long-term computer storagerepository that holds large amounts of raw data in a native format untilthe data is needed. The native format may include the time series datafrom the medical devices which may be in waveform or binary format,audio data, image data, and/or video data. In embodiments, this can helpto facilitate the ingestion of the data that may not be processed inreal time but may still be taken in in real time or near real time andinstead stored in the data lake until further needed. This may befacilitated by identifying particular data streams and limiting theprocessing of those data streams, for example by the data qualitymanagement module 24, if it is known at that time that such data streamis not being used in real time analysis. In an exemplary embodiment, thedata quality management module 24 may not convert the data to acanonical data model but may still attempt to tag, enrich, or index thedata to facilitate later retrieval of that data in a standardized wayfrom the data lake 26.

In a still further embodiment, portions of the data that are stored inthe data lake 26 may also be additionally stored in a graph databasewhich may be a separate database residing on the same computer readablestorage, or may be embodied on separate computer readable storage fromthe data lake 26. The graph database may receive the data streams ofwhich it is known that the system may analyze trends in that datastream. The graph database may store the streams of data in a timeseries format in a way that facilitates trending of the data over timeand appending the data with events either identified in the data itself,in one or more of the other data streams, or received by the system froman external source. These events may include, but are not limited to,medical device or clinician actions, clinical events, situations, orcomplications that arise during the medical procedure. The graphdatabase may later be used by a clinician or technician to identifyfurther relationships between trends and the data streams with otheranalysis as disclosed herein.

At the same time that the data is stored in the data lake 26, theenriched and normalized medical device data may be provided to a streamprocessing engine 28. The stream processing engine 28 identifies casesand events in the time series streams of medical device data. Identifiedclinical cases may be stored in an operational case database 30.Clinical cases may exemplarily include surgical and intensive care unit(ICU) cases. The clinical cases may be identified by the medical deviceused and the timing of the medical data in the time series of themedical device data. For example, a time series of medical device datafrom an anesthesia delivery machine showing a change in status turningthe machine on and followed by changes to device settings and deliveryand/or consumption of anesthetic agent all indicate that a clinical casehas begun or is ongoing.

As noted above, the streams of time series medical device dataoriginating from the same medical device or from the same location in ahospital may be tagged or otherwise identified as being related. Thesetags can be used to simultaneously analyze related data streams orcombine analysis of related data streams to identify clinical cases. Forexample, a device status data stream analysis may be combined with auser input data stream, device setting data stream, and operational datastreams to identify when the device is used and how it is used in theclinical case. This information may help to distinguish between amaintenance or checkout of the medical device by a technician from theuse of the device for clinical case.

The analysis of the data streams of multiple medical devices,particularly those identified as being related or co-located may furtherbe used to identify clinical cases. For example, coordinated or similaractions in data streams of an anesthesia delivery device and a relatedpatient monitoring device, and/or respiratory support device and/orimaging device, etc., may further be used to identify that these devicesare being used together for a clinical case. In still furtherembodiments, the streaming time series medical device data may becombined with information regarding scheduled clinical cases to help tofurther identify when and how the medical devices are used duringclinical cases.

In embodiments, knowledge of a scheduled use of the medical device (e.g.anesthesia delivery machine) can be used to further identify clinicalcases in the streams of medical device data. For example, input orreceived knowledge regarding a type and time of a scheduled proceduremay help to identify the start and end of the clinical case inparticular streams of medical device machine data. In an embodiment, aknown schedule of use for the medical device may help to identifyclinical cases from maintenance or calibration actions which maysimilarly require powering up and at least partial operation of themedical device.

The medical device data associated with the actions by the anesthesiadelivery device and/or other medical devices during the identifiedclinical case may be stored in the operational case database 30. In anexample, the identification of the clinical case is stored along withthe other time series streams of medical device data from thatanesthesia delivery machine as well as time series streams of medicaldevice data from any physiological monitors and/or other medical devicesassociated with the use of that anesthesia delivery machine. In anotherexemplary embodiment as described in further detail, a clinical casesummary with links or identifiers to the associated time series medicaldevice data stored in the data lake 26 can be created and stored in theoperational case database 30.

In an embodiment, prior to storing the clinical cases in the clinicalcase database 30, the clinical cases may be classified or profiled whichis a technique used for data curation. The profiling of the clinicalcases may be based upon, in part, the information in the clinical casesummary, and as described in further detail herein, may be used to groupthe clinical cases into groups, for example normal cases, edge cases,and outlier cases. These determinations may be made in view of acomparison between the time series data in the clinical case againstnormal distributions of the same type of time series machine data inother similar clinical cases. Edge cases may be identified as borderlineor ambiguous cases, not clearly defined as either normal or an outlier.In a merely exemplary embodiment, for a particular measured value oroccurrence, a distribution of such occurrences may be used to establishnormal, edge, and outlier cases. In a merely exemplary embodiment, anormal case may be within a standard deviation of a median value in thenormal distribution while edge cases are between one and two standarddeviations and outlier cases are greater than two standard deviationsfrom the median. The categorized cases, as explained in further detailherein, for example, identified edge cases may be further investigatedto create or improve event detection algorithms, rules for clinicaldecision support, alert algorithms, and predictive algorithms.

The stream processing engine 28 also identifies events in the timeseries streams of medical device data, for example in the manners asdescribed in further detail herein and presented in businessintelligence and visual analytics tools 32 which exemplarily may bepresented on a graphical display communicatively connected to themedical device data processing system 12.

Once clinical cases are stored in the operational case database 30,clinical cases may be reviewed manually by a clinician or technicianusing a curation and case review tool 34. The curation and case reviewtool 34 may be presented in a graphical user interface on a graphicaldisplay and further provide inputs exemplarily through the graphicaluser interface for the user or technician to curate or otherwise assessthe clinical cases. This can be performed for investigative,educational, and data curation purposes.

The reporting and visual analytics tool 32 can present the detectedevents in a variety of channels of communication. For example, thedetected events may be presented visually through graphical userinterfaces and graphical displays. The detected events or notificationsof the detected events can also be reported by communication ofevents/event notifications to wearable or mobile devices andpresentation of medical device data and identified events in visual formin reports and/or dashboards presented in a graphical user interface ona graphical display, as will be explained in more detail below.

The results of the streaming analytics and event detection in the timeseries of medical device data may be provided to an applicationprogramming interface (API) 38 for use by application developers toprovide monitoring, reporting, and/or control applications based uponthe analyzed streams of medical device data. Such applications mayoperate through a computer operating system, a website browser, oroperate on a mobile computing device or wearable computing device.Non-limiting examples of applications that may leverage the analysis ofthe time series medical device data include, but are not limited to, ananesthetic agent cost dashboard 40, a checkout dashboard 42, asupervisory application 44, an alarm management application 46, an assetmanagement application 48, and a benchmarking application 50.

The agent cost dashboard 40 may present medical device data regardinganesthetic agent use across clinical cases as well as between anesthesiadelivery machines within a hospital network or comparatively betweenhospital networks. By comparatively presenting this information,anesthetic agent use and behavioral changes can be understood andundertaken to promote efficient use of anesthetic agent.

The checkout dashboard 42 may assist in monitoring the inspection andmaintenance of the monitored medical devices. Medical device data suchas device status and settings, as well as messages and information inmachine data, may provide insight into the inspection processes formaintaining medical devices at a hospital network. The checkoutdashboard may identify maintenance and/or testing events in the streamsof machine data and note these identified testing events against atesting schedule, requirement (e.g., daily), or other criterion.

The supervisory application 44 may be used by attending and/orsupervising anesthesiologists to more efficiently manage remotepersonnel, nurse anesthetists, and/or other care providerssimultaneously working across multiple locations or theatres. The alarmmanagement application 46 may report and present medical device dataregarding alarm notifications and silences of alarm notifications inorder to better understand and adjust alarms to improve signal to noisein alarm events and to reduce alarm fatigue by clinicians. Additionalinformation about the supervisory application 44 is presented below.

The asset management applications 48 may present use, status,maintenance, and/or inspection information regarding medical devices(e.g. anesthesia delivery machines) or consumables used by medicaldevices, including components that may be frequently replaced, refilled,or refurbished during normal operation of the medical device (e.g.filters, absorbers). The benchmarking application 50 may provide furtheroperational and quality performance across providers and/ororganizations or in a comparative manner for example between hospitalnetworks versus averages or between specific locations.

The supervisory application 44 allows for users (e.g., clinicians suchas anesthesiologists, nurses, and other care providers) to viewventilator, anesthesia, and vital parameters of a plurality of patientsin different locations (e.g., in different operating rooms) on varioussmart phones, tablets, or other computing devices associated with theusers. The supervisory application 44 may include a backend that ishosted on edge device 20 and/or MDD processing system 12 asdockers/micro services and may be rendered on a user's device (such ascare provider device 134 shown in FIG. 1B) using a suitablevisualization platform.

FIG. 1B schematically shows example devices of system 10 via whichsupervisory application may be executed, including edge device 20 incommunication with a plurality of care provider devices 120 via hospitalnetwork 14 and also in communication with MDD processing system 12.

As mentioned above, the edge device 20 receives the medical device datafrom the medical devices 16. The medical device data received by theedge device 20 may be ingested by a data ingestion module 102, which maybe similar to ingestion module 22 of FIG. 1A, and stored in data storage104. Data storage 104 may be an ephemeral datastore where the receiveddata is stored temporarily rather than persistently. (The received data,such as the medical device data from the medical devices 16, may be sentto the MDD processing system 12 for long-term storage). Further, thereceived medical device data may be allocated to various micro serviceson the edge device 20 in order to carry out aspects of supervisoryapplication 44, including a stream processing module 106, a rules engine108, an inference engine 110, an event notification service 112, astreaming server 114, and a cloud gateway 116.

As explained above, the supervisory application 44 may be used byattending and/or supervising anesthesiologists to manage other careproviders, such as nurse anesthesiologists and/or other subordinate careproviders. The hospital/medical facility may rely on a relatively highsupervision ratio (e.g., 4-10 subordinate care providers for eachsupervising anesthesiologist), which may increase the need for thesupervising anesthesiologists to have high mobility among operatingrooms while still overseeing all subordinate care providers andmonitoring patient status for all procedures that may be simultaneouslyongoing. The supervisory application 44 may facilitate this mobility andmanagement by allowing supervising anesthesiologists to monitor patientstatus and communicate with subordinate care providers from a remotelocation. As will be explained in more detail below, the supervisoryapplication 44 may present, via one or more graphical user interfacesdisplayed on a mobile or other device of a supervising anesthesiologist,patient monitoring parameters (e.g., ECG, heart rate, blood oxygenation)as determined from the received medical device data, procedure phase(e.g., induction, maintenance, and emergence), alarms, anesthesiologymachine settings, and other relevant or selected information to a user(e.g., the supervising anesthesiologist). The processing and analysis ofthe time series streams of medical device data as described above inorder to detect events relevant to identified cases (e.g., such asidentifying a phase of anesthesia administration) may be utilized andthe output of such processing and analysis may be provided to thesupervisory application 44. The supervisory application 44 may providedetermined values of specified patient monitoring parameters,indications of detected events, and other notifications as determinedfrom the time series streams of medical device data to the user via thegraphical user interfaces described herein.

For example, via the supervisory application 44, the user may togglebetween graphical user interfaces that show limited information for aplurality of patients (a multi-patient GUI) and more detailedinformation for a selected patient (a single patient GUI). The user mayalso view, via the supervisory application 44, trends of patientmonitoring data, detailed alarm/notification information, insights,and/or other information. Further, the user may communicate with othercare providers, such as a subordinate care provider that is in the roomwith a patient, via the supervisory application 44. The user maycustomize which patients/rooms to view, which patient monitoringparameters to view, which alarms and insights to apply, and otherparameters of the graphical user interfaces used to present theabove-described information, such as a layout of each graphical userinterface.

The graphical user interfaces that are generated via the supervisoryapplication 44 may be displayed on one or more suitable display devicesassociated with a respective care provider device and/or medicalfacility administration device. As shown in FIG. 1B, a plurality of careprovider devices 120 may be included as part of hospital network 14,from a first care provider device 134, a second care provider device136, and on up to an nth care provider device 138, and may becommunicatively coupled to edge device 20 via hospital network 14. Eachcare provider device may include a processor, memory, communicationmodule, user input device, display (e.g., screen or monitor), and/orother subsystems and may be in the form of a desktop computing device, alaptop computing device, a tablet, a smart phone, or other device. Eachcare provider device may be adapted to send and receive encrypted dataand display medical information, including medical images in a suitableformat such as digital imaging and communications in medicine (DICOM) orother standards. The care provider devices may be located locally at themedical facility and substantially fixed in place (such as in a nursesstation or in the room of a patient) and/or located locally or remotelyfrom the medical facility and configured to move with the care provider(such as a care provider's mobile device).

When viewing graphical user interfaces generated via the supervisoryapplication 44 via a display of a care provider device, a care providermay enter input (e.g., via the user input device, which may include akeyboard, mouse, microphone, touch screen, stylus, or other device) thatmay be processed by the care provider device and sent to edge device 20.In examples where the user input is a selection of a link or userinterface control button of a graphical user interface, the user inputmay trigger progression to a desired view or state of the graphical userinterface (e.g., trigger display of desired patient medicalinformation), trigger updates to the configuration of the graphical userinterface, trigger alarm, insight, and/or other notification settings tobe saved, trigger changes to a machine (such as an anesthesia deliverymachine), or other actions.

The devices disclosed herein, such as the care provider devices and/oraspects of the edge device 20, may each include a communication module,memory, and processor(s) to store and execute aspects of the supervisoryapplication 44 as well as send and receive communications, graphicaluser interfaces, medical data, and other information.

Each communication module facilitates transmission of electronic datawithin and/or among one or more systems. Communication via thecommunication module can be implemented using one or more protocols. Insome examples, communication via the communication module occursaccording to one or more standards (e.g., Digital Imaging andCommunications in Medicine (DICOM), Health Level Seven (HL7), ANSI X12N,etc.). The communication module can be a wired interface (e.g., a databus, a Universal Serial Bus (USB) connection, etc.) and/or a wirelessinterface (e.g., radio frequency, infrared, near field communication(NFC), etc.). For example, a communication module may communicate viawired local area network (LAN), wireless LAN, wide area network (WAN),etc. using any past, present, or future communication protocol (e.g.,BLUETOOTH®, USB 2.0, USB 3.0, etc.).

Each memory may include one or more data storage structures, such asoptical memory devices, magnetic memory devices, or solid-state memorydevices, for storing programs and routines executed by the processor(s)to carry out various functionalities disclosed herein. Memory mayinclude any desired type of volatile and/or non-volatile memory such as,for example, static random access memory (SRAM), dynamic random accessmemory (DRAM), flash memory, read-only memory (ROM), etc. Theprocessor(s) may be any suitable processor, processing unit, ormicroprocessor, for example. The processor(s) may be a multi-processorsystem, and, thus, may include one or more additional processors thatare identical or similar to each other and that are communicativelycoupled via an interconnection bus.

As used herein, the terms “sensor,” “system,” “unit,” or “module” mayinclude a hardware and/or software system that operates to perform oneor more functions. For example, a sensor, module, unit, or system mayinclude a computer processor, controller, or other logic-based devicethat performs operations based on instructions stored on a tangible andnon-transitory computer readable storage medium, such as a computermemory. Alternatively, a sensor, module, unit, or system may include ahard-wired device that performs operations based on hard-wired logic ofthe device. Various modules or units shown in the attached figures mayrepresent the hardware that operates based on software or hardwiredinstructions, the software that directs hardware to perform theoperations, or a combination thereof.

“Systems,” “units,” “sensors,” or “modules” may include or representhardware and associated instructions (e.g., software stored on atangible and non-transitory computer readable storage medium, such as acomputer hard drive, ROM, RAM, or the like) that perform one or moreoperations described herein. The hardware may include electroniccircuits that include and/or are connected to one or more logic-baseddevices, such as microprocessors, processors, controllers, or the like.These devices may be off-the-shelf devices that are appropriatelyprogrammed or instructed to perform operations described herein from theinstructions described above. Additionally or alternatively, one or moreof these devices may be hard-wired with logic circuits to perform theseoperations.

One or more of the devices described herein may be implemented over acloud or other computer network. For example, edge device 20 is shown inFIG. 1B as constituting a single entity, but it is to be understood thatedge device 20 may be distributed across multiple devices, such asacross multiple servers.

The supervisory application 44 may provide various data, notifications,and messages to the plurality of care provider devices 120. The data,notifications, and/or messages may include historical data, real-timemedical device data (e.g., provided by streaming server 114), andnotifications that may pushed to the plurality of care provider devices120 from an event notification service 112 via MDD processing system 12or another a cloud-based service.

As will be explained in more detail below, the supervisory application44 may be visualized on a care provider device in the form of one ormore graphical user interfaces. The one or more graphical userinterfaces may be populated with real-time patient monitoringparameters, such most-recently determined values or waveforms for heartrate, blood oxygen saturation, respiration rate, and so forth, obtainedfrom the medical devices. When the medical device data is received bythe edge device 20, some or all of the medical device data may beprocessed by stream processing module 106 and supplied to the streamingserver 114, which may then supply the real-time patient monitoringparameter values and/or waveforms to a requesting care provider device.For example, when a user is viewing a patient-specific graphical userinterface of the supervisory application 44 on care provider device 134,the graphical user interface may include tiles or other display areaswhere the most-recently determined values for selected patientmonitoring parameters are displayed (for example, as shown in FIGS. 2and 4A and explained in more detail below). The streaming server 114 maystream the most-recently determined values for the selected patientmonitoring parameters to the care provider device 134, which may thenpopulate the received values into the graphical user interface. Thestream processing module 106 may include rule-based streaming analyticsalgorithms applying windowing functions (sliding, tumbling, hopping,etc.) used for waveform analysis and event detection, thereby triggeringalerts, detection of surgical phases, flow analysis, triagingalgorithms, etc. Furthermore, the stream processing module 106 coupledwith inference engine 110 may perform predictions such as continuouslypredictive scoring, patient deterioration scoring, calculate riskindexes, identify early signs of trouble, sepsis prediction, onset ofrespiratory distress, end-of-case prediction, and clinical decisionsupport in general.

The determination of which patient monitoring parameter values to sendto which care provider device may be based at least in part on datarequests sent by the care provider devices to the edge device 20. Theedge device 20 may include a representational state transfer (REST)server, for example, that may receive data requests from the careprovider devices 120 and may respond to the data requests by commandingthe streaming server 114 to stream selected medical device data to arequesting care provider device(s). The streaming server 114 maymaintain a stateful session (e.g., WebSocket) with each client (e.g.,the care provider devices). The medical device data may be adapted(transformed and filtered) before being streamed to the client devices.

The data requests from the care provider devices 120 may also includerequests for historical data (e.g., prior or non-real time patientmonitoring parameter values). The historical data may include trends ofselected patient monitoring parameters over time. For example, as shownin FIG. 6 and explained in more detail below, a trends graphical userinterface may be displayed on a care provider device as part of thesupervisory application 44 that shows values for selected patientmonitoring parameters over time as trend lines. The trend lines may beassembled from stored medical device data (e.g., stored in data storage104). When a user requests to view a trends graphical user interface ona care provider device, the care provider device may send a request forthe trend lines that are to be displayed in the trends graphical userinterface to the edge device 20, and the edge device 20 may obtain thetrend lines from the data storage 104 or the edge device 20 may obtainrelevant stored medical device data and the trend lines may be assembledat a different location (e.g., by the care provider device).

In some examples, users may communicate with one another via thesupervisory application 44. For example, as shown in FIG. 22 anddescribed in more detail below, an in-room graphical user interface maybe displayed on a care provider device as part of the supervisoryapplication 44. The in-room graphical user interface may include amessage view where a care provider in the room with a patient (e.g., anurse) may communicate with another care provider located outside theroom (e.g., an anesthesiologist) via text messages, for example. Themessages sent and received via the supervisory application may be routedthrough the edge device 20 and/or the MDD processing system 12. Forexample, a first care provider device (e.g., care provider device 134)may send a message intended for a second care provider device (e.g.,care provider device 136). The message may be sent from the first careprovider device to the edge device 20 and a messaging module of the edgedevice 20 may receive the message, determine the intended recipient careprovider device, and send the message to the intended care providerdevice (e.g., the second care provider device).

The supervisory application 44 may generate and/or send various alarmsand notifications based on the medical device data received from thevarious medical devices. The alarms may include threshold-based alarms,where a notification/alarm is generated and output to one or more careprovider devices in response to a patient monitoring parameter valuemeeting a predetermined condition relative to a threshold (e.g., analarm may be generated and sent to a care provider device in response toblood oxygen saturation for a particular patient dropping below athreshold saturation). For example, as shown in FIG. 9 and explained inmore detail below, an alarm tile may be displayed as part of asingle-patient or multi-patient graphical user interface of thesupervisory application 44, where the alarm tile includes an indicationof how many alarms have been triggered for a particular patient, wherean alarm is generated by a medical device in response to a determinationthat a patient monitoring parameter for a particular patient has reacheda predefined condition relative to a threshold.

The alarms described above may be triggered by a medical devicemonitoring the patient. For example, the patient may be monitored by apulse oximeter, which may send SpO2 data to edge device 20 directly orvia an anesthesia delivery machine. If the patient's blood oxygensaturation drops below a threshold, the pulse oximeter and/or anesthesiadelivery machine may send a notification to edge device 20 indicatingthat the patient's SpO2 value has dropped below a threshold. Edge device20, via event notification service 112 and/or cloud gateway 116, maysend a notification of the alarm to the care provider device of the careprovider attending to the patient. For example, the alarms that aregenerated may be sent to the appropriate care provider device(s)directly via event notification service 112 or via the cloud gateway116, which may push the alarms (and other notifications that aregenerated by edge device 20, as explained in more detail below) via MDDprocessing system 12 to the appropriate care provider device(s), evenwhen the supervisory application 44 is in an unlaunched state on thecare provider device(s).

As mentioned above, the supervisory application 44 is configured toapply insights to the received medical device data in order to provideuser-selected notifications, predictions, etc., of patient status. Theinsights may include the rule-based streaming analytics algorithmsperformed by the stream processing module 106 and/or inference engine110 described above (e.g., waveform analysis and event detection,thereby triggering alerts, detection of surgical phases, flow analysis,triaging algorithms, continuously predictive scoring, patientdeterioration scoring, calculate risk indexes, identify early signs oftrouble, sepsis prediction, onset of respiratory distress, end-of-caseprediction, and clinical decision support). The insights may includeartificial intelligence based models, such as machine learning or deeplearning models. In general, any algorithm, model, or set of rules thatmay be applied to the medical device data in order to monitor patientstate may be considered an insight. In some examples, particularly wherethe insight requires a high amount of processing power, the insight maybe stored/executed on a cloud based device such as the MDD processingsystem 12.

In some examples, insights may be defined by a user according to apredefined set of parameters and a predefined set of operators and savedas a set of rules. The predefined set of parameters may include all thepatient monitoring parameters (including physiological data and machineparameters/settings) that are available to the system (e.g., all thepatient monitoring parameters that can be measured, inferred, orotherwise determined from the medical device data). When a parameter isselected (e.g., when a patient monitoring parameter is selected), theuser may be presented with a predefined scopes (e.g., timings) to selectto limit the insight to specific procedures, timing, etc. Further, whena parameter is selected, the user may be presented with predefined oradjustable thresholds to apply to the parameter. The predefined set ofoperators may include an “and” operator, an “or” operator, a “while orduring” operator, and/or any other suitable operators that allow theuser to combine multiple parameters in an insight, or allow the user toselect only one parameter for the insight.

The rules engine 108 may include resources (e.g., memory and processors)of the edge device 20 allocated to store and apply sets of insightrules, which may be similar to alarms, but may be multi-modal and/ormulti-parameter. The insights may be user-customized/defined. Theinsight rules may define a condition and a scope of each insight. Forexample, as shown in FIG. 20 and explained in more detail below, aninsight may include a condition that defines a patient monitoringparameter and corresponding threshold value that may trigger the insightnotification, such as patient heart rate being above 150 beats/minute.An insight may further include a scope, which may be a timing- orprocedure-based limitation on when the condition of the insight willtrigger a notification or result. For example, the scope may define theparameters during which the condition is to be applied, such as how longthe condition is to persist before triggering the insight notification(e.g., five minutes), which stage of the procedure the condition is tooccur in order to trigger the insight notification (e.g., in maintenancestage of anesthesia delivery), and so forth. As explained above, theuser may define the condition and scope from the predefined set ofparameters, and if more than one condition is desired in an insight, theuser may select an operator from the predefined set of operators. Whenmultiple conditions are included in an insight, after selecting anoperator such as “and” or “or,” the user may select another parameterfrom the set of parameters.

The insight rules may be customized by user, and thus the insight rulesmay define which users (and hence which care provider devices) are toreceive which insight notifications. The edge device 20 may distributemedical device data streams to the rules engine 108, and the rulesengine 108 may apply the stored insight rules to the incoming streams ofmedical device data in order to determine if any insight notificationsor results should be generated. If an insight notification is to begenerated, an insight notification may be generated and sent to theappropriate care provider device(s) via the event notification service112 and/or cloud gateway 116.

In some examples, an insight may include, as an input, the result ofanother insight. For example, a first insight may include an algorithmthat determines a current anesthesia delivery phase for an anesthesiadelivery machine. The output/result of the first insight may bedisplayed as a tile on a GUI of the supervisory application that isdisplayed on a care provider device, as will be explained in more detailbelow. The result of the first insight may also be used as input, alongwith the medical device data, to a second insight. For example, thesecond insight may dictate that a notification be output when a selectedpatient monitoring parameter value reaches a threshold value (or when achange in a selected patient monitoring parameter over a particular timeperiod reaches a threshold) when the result from the first insightindicates that the patient is in maintenance phase of anesthesiadelivery. A user may select to include the result of an insight as aninput into another insight via the predefined set of parametersdescribed above. For example, when the user creates an insight orapplies an insight created by another user, that insight may be includedin the predefined set of parameters.

Further, insights may be shared with other users at the medical facilityand/or other users at other medical facilities. Thus, when requested,insight rules may be saved at the MDD processing system 12. As shown inFIG. 17 and explained in more detail below, an insight graphical userinterface of the supervisory application 44 may be displayed on a careprovider device when requested. Via the insights graphical userinterface, a user may search for insights defined by users at othermedical facilities and/or for insights defined by users at the samemedical facility as the user is located, as well as view insightsdefined by the user. If the user selects to apply an insight, thenotification that the insight has been selected may be sent to the rulesengine 108 and/or the inference engine 110 and saved as an insight ruleto be applied for that user.

The inference engine 110 may be used with artificial intelligence (AI)based models, such as trained deep learning models, to process theincoming data and derive conclusions (insights) from the facts and rulescontained in the various machine learning models. The inference engine110 may be the run-time engine for AI based algorithms, such asprediction of signs of trouble, and these will be part of the inferenceengine 110. In addition, there may be a deep learning and/or learningnetwork in the cloud, e.g., MDD processing system 12, to trainalgorithms, where very high compute and resources are necessary.

As explained above, and will be explained in more detail below, via aninsights engine feature of the supervisory application 44, users maycreate their own rules/algorithms from within a user interface andcurrent available data to generate insights, based on theirpre-configuration. The insights engine uses streaming, and applieswindowing functions, to generate the insights. These insights are thennotified to the respective users, based on the users' configuration(e.g., user-subscribed insights), using the event notification service112. The available data to create a rule may include raw machine data,or the result of an AI algorithm powered by the inference engine 110(e.g., another insight).

When a user creates their own insight (e.g., rule/algorithm) through theinsights engine, they have the opportunity to share that the insightwith other users, so other users can adopt and use the same insight. Forexample, a user may share an insight within the user's institution andother users can see how many people are using the insight and adopt theinsight for their own patients/rooms. A user may also see rules (or“insights”) that others on the platform outside the user's institutionglobally have set up, and see the popularity of each insight, and ifdesired, select one or more of the insights to be applied for their ownpatients/rooms.

Thus, as explained above, the supervisory application 44 may include abackend hosted on the edge device 20, where the backend includes aplurality of micro services, such as the rules engine 108, inferenceengine 110, event notification service 112, and streaming server 114.The supervisory application 44, via the backend/edge device 20, mayoutput real-time medical device data to a plurality of care providerdevices, trends of medical device data, messages, alarms, insightnotifications/results, and/or other information as requested by thefront end of the supervisory application 44 that is executed on the careprovider devices. The front end of the supervisory application 44 mayinclude a supervisory application visualization platform that may bestored on each care provider device. The supervisory applicationvisualization platform, such as supervisory application visualizationplatform 135 stored on care provider device 134, may render the datareceived from the edge device 20 into one or more graphical userinterfaces. Additionally, the aspects of the supervisory application 44that are saved on each care provider device may include variouscontainer, component, and presentation layers to receive the data fromthe edge device 20, populate the graphical user interfaces with thereceived data, send and receive messages, display notifications, collectGUI settings and other requested customizations (and send thesettings/configurations to the edge device 20) and so forth. As anexample, the historical data received form the edge device 20 (e.g., thetrends) may be sent to a first layer via a REST application programminginterface (API), the real-time medical device data may be streamed tothe first layer via a web socket, and the push notifications sent fromthe MDD processing system 12 may be received, processed, and displayedvia the visualization platform. Further, when interacting with thegraphical user interfaces of the supervisory application, the user mayadjust various settings (such as which patient monitoring parameters todisplay) activate or deactivate alarm notifications, create insights,and so forth. These user-specific preferences/configurations may besaved on the edge device 20 in a preferences/configuration database.

In some embodiments, medical device data and/or other informationrequested via the supervisory application 44 may be obtained from anelectronic medical records (EMR) database 122. For example, historicaldata (e.g., trend lines) may be obtained from the EMR database 122 inaddition to or instead of data storage 104. EMR database 122 may be anexternal database via a secured hospital interface, or EMR database 122may be a local database (e.g., housed on a device of the hospital). EMIRdatabase 122 may be a database stored in a mass storage deviceconfigured to communicate with secure channels (e.g., HTTPS and TLS),and store data in encrypted form. Further, the EMR database 122 isconfigured to control access to patient electronic medical records suchthat only authorized healthcare providers may edit and access theelectronic medical records. An EMIR for a patient may include patientdemographic information, family medical history, past medical history,lifestyle information, preexisting medical conditions, currentmedications, allergies, surgical history, past medical screenings andprocedures, past hospitalizations and visits, etc.

The edge device 20 can be implemented in a variety of hardware and/orsoftware implementations and it should be noted that suchimplementations are not considered to be limiting. For example, it iscontemplated that any or all of the edge device 20 may be embodiedexclusively in hardware, exclusively in software, exclusively infirmware, or in any combination of hardware, software, and/or firmware.The examples provided herein are not the only way to implement suchmethods and systems.

In exemplary and non-limiting embodiments of the edge device, the edgedevice 20 is implemented by one or more processors or computing devices.Memory and processors as referred to herein can be standalone orintegrally constructed as part of various programmable devices,including for example, computers or servers. Computer memory of computerreadable storage mediums as referenced herein may include volatile andnon-volatile or removable and non-removable media for a storage ofelectronic-formatted information such as computer readable programinstructions or modules of computer readable program instructions, data,etc. that may be stand-alone or as part of a computing device. Examplesof computer memory may include, but are not limited to, RAM, ROM,EEPROM, flash memory, CD-ROM, DVD-ROM or other optical storage, magneticcassettes, magnetic tape, magnetic disc, or other magnetic storagedevices, or any other medium which can be used to store the desiredelectronic format of information and which can be accessed by theprocessor or processors or at least a portion of a computing device.

FIG. 2 shows an example single-patient graphical user interface (GUI)200 that may be displayed when supervisory application 44 is launched ona supervising care provider device. Single-patient GUI 200 may bedisplayed on a display device 202. Display device 202 may include ascreen on which the single-patient GUI is displayed and may be coupledto and/or included as a part of a computing device, such as careprovider device 134. Single-patient GUI 200 may be displayed in responseto a user request to display the GUI. For example, a user may launch thesupervisory application 44 by selecting a supervisory application icondisplayed on a home page of the display device. When the supervisoryapplication 44 launches (at least initially), the user may beauthenticated via a suitable authentication method, such as via apassword, facial recognition, fingerprint recognition, etc. Uponauthentication, the user may select to view the single-patient GUI 200from a suitable menu. For example, the user may access a multi-patientinterface that includes a global view of all patients the user hasselected to monitor (which may include all patients at the medicalfacility the care provider is attending to) and may select a desiredpatient to view. An example multi-patient GUI 1300 is shown in FIG. 13.Multi-patient GUI 1300 may be displayed on display device 202 (or othersuitable display device associated with a care provider device) and mayinclude all patients/rooms selected by a user for monitoring. As shown,multi-patient GUI 1300 includes links to patient-specific interfaces. Inthe examples shown herein, rather than identifying each patient by nameor a patient ID number, each patient-specific interface may beidentified by the room that patient is currently located in. Forexample, as shown in FIG. 13, links are displayed for interfacesspecific to patients located in a first operating room (OR 1), a secondoperating room (OR 2), a third operating room (OR 3), and so forth.Additional patient links may be viewed by scrolling the interface.Selection of a patient link may launch the single-patient GUI for thatpatient. For example, selection of forward button 1301 for OR 2 maycause the single-patient GUI 200 to be displayed.

Returning to FIG. 2, single-patient GUI 200 may include anidentification header 204 that identifies the patient whose medicaldevice data/status is being displayed, in the form of the room in whichthe patient is currently located. In the illustrated example,single-patient GUI 200 is specific to the patient located in the secondoperating room of the medical facility (OR 2). Identification header 204may include a back button 206, which when selected via user input (e.g.,via touch input to the back button) may cause display of a multi-patientGUI (such as multi-patient GUI 1300 of FIG. 13). Identification header204 may further include one or more menu buttons, such as menu button208. When menu button 208 is selected, a context menu may be displayed,which will be explained in more detail below with respect to FIG. 5.

Identification header also includes a parameter view button 210 that,when selected causes display of a parameter view where machinesettings/parameters for the one or more medical devices monitoring thepatient and/or delivery therapy to the patient (such as machine settingsfor an anesthesia machine) are displayed. FIG. 3 shows an exampleparameter view 300 displayed on display device 202 in response toselection of the parameter view button 210. Parameter view 300 displaysmachine parameters in a first layout that includes an array of tiles.Each selected machine parameter may be displayed as a respective tile,such as a first tile 210, a second tile 212, and a third tile 214. Inthe example shown in FIG. 3, the first tile 210 displays a firstparameter, oxygen percentage, the second tile 212 displays a secondparameter, oxygen or medical gas flow rate to the patient, and the thirdtile 214 displays a third parameter, anesthetic agent type andconcentration. Each parameter tile that is displayed via the parameterview 300 may present a most-recently determined value of the respectivemachine parameter. For example, the first tile 210 is presenting anoxygen concentration of 95%, the second tile 212 is presenting a gasflow rate of 6.50 L/min, and the third tile 214 is presenting asevoflurane concentration of 2.5%. Each determined value that ispresented via a machine parameter tile may be determined from the timeseries streams of medical device data described above with respect toFIGS. 1A and 1, and as such may be sent to the care provider device fromthe edge device 20 via the supervisory application 44. The determinedvalues that are displayed in the parameter view 300, as well as otherdetermined values (such as the patient monitoring parameter values thatwill be explained in more detail below) may be measured values,estimated values, and/or inferred values. For example, SpO2 may bedirectly measured from a pulse oximeter, while respiration rate may beinferred from the output of a capnography or from the output form thepulse oximeter.

The patient monitoring parameter tiles included in the single-patientGUI 200 (described below) may present physiological data (e.g., SpO2,respiration rate) of the patient as obtained from one or more patientmonitoring medical devices (e.g., a pulse oximeter, a capnograph). Themachine parameter tiles included in the single-patient GUI 200 and/orparameter view 300 may present machine data of one or more therapymedical devices that are being utilized during a medical procedure beingperformed on the patient, such as an anesthesia delivery machine. Themachine data may include machine settings or parameters (e.g.,ventilator mode, anesthesia type and concentration).

Returning to FIG. 2, single-patient GUI 200 further includes an insightstile 302, a message tile 304, an alarms tile 306, and a procedure timingtile 308. The insights tile 302 may notify the user if any of the user'spreset and saved insights have been triggered, which will be explainedin more detail below. Briefly, the insights may be similar tothreshold-based alarms, but may be multi-modal and/or multi-parametersuch that an insight may only be triggered when more than one parametermeets a predetermined condition and/or when a selected parameter meets apredetermined condition during a particular stage of a medicalprocedure, meets the predetermined condition for a specified amount oftime, changes at a specified rate, etc. The messages tile 304 may notifythe user if any messages have been received, such as text messages fromanother care provider. The alarms tile 306 may notify the user if anyalarms have been triggered. An alarm may be triggered when a selectpatient monitoring parameter, such as SpO2, reaches a predeterminedcondition relative to a threshold, such as SpO2 dropping below 90%. Theprocedure timing tile 308 may inform the user of the current progress onthe medical procedure being performed on the patient. For example, asshown in FIG. 2, an amount of elapsed time since commencement ofanesthesia delivery is shown (e.g., 02:12:15), as well as the currentphase of the anesthesia delivery (e.g., maintenance phase). The phase ofanesthesia delivery may be determined by a phase determining insightthat may be executed by the MDD processing system 12 and/or edge device20, as explained above with respect to FIGS. 1A and 1B.

Additional patient monitoring parameters that are displayable viasingle-patient GUI 200 may be organized into categories, and eachpatient monitoring category may be collapsed or expanded. Whencollapsed, no patient monitoring parameters for that category aredisplayed. When expanded, the patient monitoring parameters for thatcategory are displayed. FIG. 2 shows each category in a collapsedconfiguration. The patient monitoring categories shown in FIG. 2 includea circulation category 310, an oxygenation category 312, a ventilationcategory 314, and a neurology category 316, although other categoriesare possible without departing from the scope of this disclosure. Thedisplayed patient monitoring categories may be customized by the user,such that the user may select which categories will be displayed on thatuser's device. Each patient monitoring category includes a forwardarrow, such as forward arrow 318, which when selected by the user causesthe category to expand so that the patient monitoring parameters in thatcategory may be viewed.

FIG. 4A shows a first view 400 of a progression through different viewsof single-patient GUI 200. In the first view 400, the user has selectedtwo categories to expand (the circulation category 310 and theoxygenation category 312) and two categories remain collapsed (theventilation category 314 and the neurology category 316). When acategory is expanded, the associated forward arrow may switch to a downarrow, as shown by down arrow 402, to signify that the category has beenexpanded. User selection of the down arrow causes the category tocollapse.

As appreciated by FIG. 4A, when a category is expanded, a plurality ofpatient monitoring parameters may be displayed. For example, thecirculation category 310 includes eight patient monitoring parameters(e.g., an ECG waveform, a most-recently determined heart rate, and soforth) each related to circulation. The oxygenation category 312includes six patient monitoring parameters (e.g., a most-recentlydetermined SpO2), each related to oxygenation. The patient monitoringparameters that are included in each category may be selected by theuser via an edit function, which may be executed via the context menu ofFIG. 5 or by a user input made to a category. For example, a swipemotion on the circulation category 310 banner may trigger display of anedit button. Selection of the edit button may trigger control buttons tobe displayed, via which patient monitoring parameters in the categorymay be deleted and/or additional patient monitoring parameters may beadded. In this way, the edit/customization functionality gives the powerto the user to view any parameter in the system using the single-patientGUI, including a trend of that parameter, within a tile. For example,via the edit function, the user may choose to view a patient monitoringparameter as a single value (e.g., most recently determined value), as atrend showing change in the patient monitoring parameter over time, orboth. The user has the power to create their own views, their owninsights, and so forth, as will be explained in more detail below.

As explained above, one or more of the patient monitoring parametersthat are displayed in the expanded view of a category may include amost-recently determined value for that parameter. For example, in theoxygenation category 312, an SpO2 tile 404 may be displayed, showing themost-recently obtained SpO2 value. However, it may be beneficial for theuser to view a change in the values of a patient monitoring parameterover time. To access a view where one or more patient monitoringparameter trends are displayed, the user may enter an input to aselected patient monitoring parameter tile, such as a single touch input(schematically shown by hand 406) to SpO2 tile 404. Selection of thepatient monitoring parameter tile may trigger a trend view for theselected patient monitoring parameter, as shown in FIG. 4B.

FIG. 4B shows a second view 420 of single-patient GUI 200 displayed ondisplay device 202. Second view 420 includes a set of trends 422 thatmay be displayed in response to user selection of the SpO2 tile 404. Theset of trends 422 may be displayed as an overlay on top of the firstview 400, or the set of trends 422 may be displayed as a separatewindow, taking the place of or fully obscuring the first view 400. Theset of trends 422 includes an SpO2 trend line 424 and a plurality ofrelated trend lines, herein the fraction of inspired air comprised ofoxygen (FiO2), end-tidal CO2 (EtCO2), blood pressure (NIBP, includingdiastolic and systolic measurements), and heart rate (HR). Each trendline is plotted on its own y-axis, such that the values of each patientmonitoring parameter may be plotted on different scales and withdifferent units where applicable. Each trend line is plotted on a commonx-axis, so that the trend lines are time-aligned. The trend lines may bestacked vertically. In this way, relationships or correspondence ofchanges among the displayed patient monitoring parameters may be easilyidentified by a viewer.

The patient monitoring parameter trends that are displayed along withthe SpO2 trend line 424 in response to the selection of the SpO2 tile404 may include trends of patient monitoring parameters not necessarilyincluded in the oxygenation category 312. For example, EtCO2 may bedisplayed as part of the ventilation category 314, while NIBP and HR areeach displayed as part of the circulation category 310. FiO2 may not bedisplayed in any of the categories shown in FIG. 4A. In this way, thepatient monitoring parameters may be grouped together in categoriesbased on the relatedness of what each patient monitoring parameter isdetecting, which may aid the user in being able to quickly navigate toview a desired patient monitoring parameter(s) when viewing the firstview 400 or another view that shows the most-recently determined valuesfor each patient monitoring parameter. Then, when the user wants to viewa trend for a selected patient monitoring parameter, other patientmonitoring parameters that have been predetermined to be related to theselected patient monitoring parameter, or otherwise have beenpredetermined to be informative about past or current patient status,may be presented along with the selected patient monitoring trend,without the user having to enter additional inputs.

The patient monitoring parameter trends that are displayed along withthe selected patient monitoring trend may be predetermined by the user,e.g., via a settings menu. In other examples, the patient monitoringparameter trends that are displayed along with the selected patientmonitoring trend may be automatically determined by the supervisoryapplication 44. For example, the supervisory application may includedefault sets of related patient monitoring parameters, and when onepatient monitoring parameter in a set is selected, all other patientmonitoring parameters in that set may also be displayed. In someexamples, the supervisory application 44 may learn or otherwise adjustover time which patient monitoring parameter trends should be displayedtogether.

The second view 420 further includes time range control buttonsdisplayed along a bottom of the set of trends 422. For example, a firsttime range control button 426 may be selected to show the set of trendsover a first time range (e.g., 10 minutes), a second time range controlbutton 428 may be selected to show the set of trends over a second timerange (e.g., 30 minutes), and a third time range control button 430 maybe selected to show the set of trends over a third time range (e.g., theentirety of the case/procedure). However, other time ranges are possiblewithout departing from the scope of this disclosure.

In some examples, user input to the set of trends 422 may cause displayof a timeline 432. The timeline 432 may include a vertical linebisecting each trend line at a given point in time. The timeline 432 maybe moved (e.g., drug) along the x-axis to a desired time point. Further,instantaneous values of each patient monitoring parameter at the timepoint corresponding to the position of the timeline may be displayedalongside the timeline 432. For example, in FIG. 4B, the timeline 432 ispositioned at 09:46, and thus values for SpO2, FiO2, EtCO2, NIBP, and HRdetermined at or near 09:46 (or, depending on the frequency at whicheach patient monitoring parameter is determined, an inference of thevalue at that time) are displayed next to the timeline 432.

The second view 420 further includes, at least in some examples, atrends icon 434. User selection of the trends icon 434 may cause atrends GUI to be displayed, which will be explained in more detail belowwith respect to FIGS. 6 and 7. Additionally, the second view 420includes a back button 436. When selected, the back button 436 maytrigger display of the first view 410 and/or other view of thesingle-patient GUI that was previously displayed.

FIG. 4C shows a third view 440 of the single-patient GUI 200. In thethird view 440, the circulation category 310 has been collapsed, theoxygenation category 312 remains expanded, the ventilation category 314is expanded, and the neurology category 316 remains collapsed. In theexample shown in FIG. 4C, the ventilation category 314 includes ninepatient monitoring parameters (e.g., EtCO2, respiration rate (RR),plateau pressure (Pplat), and so forth) each related to ventilation.

As explained above, the user may select a patient monitoring parametertile in order to view a trend for that patient monitoring parameter overtime. In the example shown in FIG. 4C, the user is selecting arespiration rate (RR) tile 442 via a touch input (shown schematically byhand 444). Selection of the respiration rate tile 442 causes a set oftrends to be displayed as an overlay across a portion of the third view440, as shown in FIG. 4D.

FIG. 4D shows a fourth view 460 of single-patient GUI 200. In the fourthview 460, a set of trends 462 is displayed at a bottom portion of thesingle-patient GUI 200. The set of trends 462 includes a trend line 464for respiration rate, as the set of trends 462 was displayed in responseto user selection of the respiration rate tile 442, as explained abovewith respect to FIG. 4C. The set of trends 462 includes a plurality ofrelated trend lines, herein blood pressure (NIBP, including diastolicand systolic measurements), heart rate (HR), end-tidal concentration ofsevoflurane (EtSev), and anesthesia phase (e.g., induction, maintenance,or emergence). Each trend line is plotted on its own y-axis, such thatthe values of each patient monitoring parameter may be plotted ondifferent scales and with different units where applicable. Each trendline is plotted on a common x-axis, so that the trend lines aretime-aligned. The trend lines may be stacked vertically. In this way,relationships or correspondence of changes among the displayed patientmonitoring parameters may be easily identified by the user.

As explained previously, the patient monitoring parameter trends thatare displayed along with the respiration rate trend line 464 may includetrends of patient monitoring parameters not necessarily included in thesame category as respiration rate. Further, the patient monitoringparameter trends that are displayed along with the respiration ratetrend may be predetermined by the user or determined automatically bythe supervisory application.

The fourth view 460 further includes time range control buttonsdisplayed along a bottom of the set of trends 462. For example, a firsttime range control button 466 may be selected to show the set of trendsover a first time range (e.g., 10 minutes), a second time range controlbutton 468 may be selected to show the set of trends over a second timerange (e.g., 30 minutes), and a third time range control button 470 maybe selected to show the set of trends over a third time range (e.g., theentirety of the case/procedure). However, other time ranges are possiblewithout departing from the scope of this disclosure. When prompted, atimeline 472 may be displayed, similar to the timeline 432 describedabove.

The fourth view 460 further includes, at least in some examples, atrends icon 474. Additionally, the fourth view 460 includes a swipe tab476. When the user makes a down-swipe motion to the swipe tab 476, theset of trends 462 may collapse to reveal the categories/patientmonitoring parameters displayed in the third view 440. When the set oftrends is collapsed, the swipe tab 476 may be visible, and an up-swipemotion to the swipe tab 476 may cause the set of trends 462 to bedisplayed again.

In some examples, when the user selects a patient monitoring parametertile, the resultant set of trends may be displayed in the manner shownin FIG. 4D when the display device 202 is at a first orientation (e.g.,portrait, with the longitudinal axis of the display device orientedvertically with respect to the ground) and the set of trends may bedisplayed in the manner shown in FIG. 4B when the display device 202 isat a second orientation (e.g., landscape, with the longitudinal axis ofthe display device orientated horizontally with respect to the ground).

While FIGS. 4C and 4D illustrated a patient monitoring parameter trendand a set of additional trends of related patient monitoring parameters,in some examples, when a patient monitoring parameter tile is selected,a more detailed trend view for only that patient monitoring parametermay be shown. For example, referring back to FIG. 4A, one of the patientmonitoring parameter tiles included in the circulation category is anECG tile, where the patient's ECG signal is represented by a singlewaveform. However, ECG monitors may include multiple electrodes/leads,such as 12, each generating a respective ECG signal. Selection of theECG tile may cause a trends view to be displayed where only ECG signalsare shown, such as the signals from some or all of the ECG leads.

FIG. 5 shows a context menu 500 that may be displayed as part of asingle-patient GUI, such as single-patient GUI 200. The context menu 500may be displayed in response to user selection of the menu button 208.The context menu 500 may be displayed as an overlay on top of anexisting view of the single-patient GUI (as shown in FIG. 5) or as aseparate menu.

The context menu 500 may include a plurality of control buttons that maytrigger different actions. For example, the context menu 500 may includea trends button 502, an insights engine button 504 (which may triggerdisplay of an insights GUI, as will be described in more detail belowwith respect to FIGS. 17-20), an edit room button 506, and a room layoutset of buttons 508. The room layout set of buttons 508 may include abutton for each different possible layout for how the single-patient GUIis configured for display. For example, a first layout (e.g.,corresponding to single-patient GUI 200) may be displayed when the“Default 1” button is selected, a second default/preconfigured layoutmay be displayed when the “Default 2” button is selected, and a thirdlayout (which may be a layout customized by the user) may be displayedwhen the “Customize 1” button is selected. When a user makes adjustmentsto the layout of a single-patient GUI, including changing which patientmonitoring parameter tiles are included in the single-patient GUI, theuser may save the layout of the single-patient GUI, which may then beselectable as a customized layout from the context menu.

When the edit room button 506 is selected, the single-patient GUI (inthe chosen layout) may be displayed with selectable control buttonsdisplayed for each currently-selected patient monitoring parameter. Userinput to a control button may toggle that patient monitoring parameterbetween being selected (and thus included in the GUI) and not selected(and thus not included in the GUI). Additional patient monitoringparameter(s) may be added via an add control button. Further details ofhow patient monitoring parameters may be added to a GUI are presentedbelow with respect to FIGS. 15 and 16. In some examples, when a patientmonitoring parameter is added to the GUI or removed from the GUI, one ormore of the remaining patient monitoring parameter tiles may be adjusted(e.g., moved from a first location to a second location, resized,rescaled, adjusted to show more or less information) in order toaccommodate the new patient monitoring parameter tile, present avisually pleasing and easy to view arrangement of tiles, show as muchinformation as possible on the display, etc. The adjustment of the oneor more remaining tiles may be performed automatically, or the user maymake desired adjustments in the manner described herein.

In the example shown in FIG. 5, a touch input is being entered to thetrends button 502 (shown schematically by hand 510). Selection of thetrends button 502 causes a trends GUI to be displayed. FIG. 6 shows anexample trends GUI 600 that may be displayed in response to selection ofa trends button from a context menu (e.g., selection of trends button502) and/or in response to selection of a trends icon (e.g., trends icon474). Trends GUI 600 is specific to a selected patient, herein thepatient located in OR 2. Trends GUI 600 includes an identificationheader 604 that identifies the patient for which the trends are beingdisplayed, including a back button 606 and an edit button 608. Whenselected, the edit button 608 may allow a user to select which trends toview via the trends GUI 600. The trends GUI 600 may be similar to thesets of trends that may be displayed in response to user selection of apatient monitoring parameter, as explained above with respect to FIGS.4B and 4D. As such, the trends GUI 600 may include a set of trends 610for each of a plurality of patient monitoring parameters, time-alignedand stacked vertically. When prompted, trends GUI 600 may display atimeline 612, similar to the timeline 432 described above, that bisectseach trend line and that may be moved along the x-axis to a desiredtime. As explained above, the timeline 612 may include an instantaneousvalue for each patient monitoring parameter at the time coinciding withthe position of the timeline 612.

The trends GUI 600 further includes time range control buttons displayedalong a bottom of the set of trends 610. For example, a first time rangecontrol button 614 may be selected to show the set of trends over afirst time range (e.g., 10 minutes), a second time range control button616 may be selected to show the set of trends over a second time range(e.g., 30 minutes), and a third time range control button 618 may beselected to show the set of trends over a third time range (e.g., theentirety of the case/procedure). However, other time ranges are possiblewithout departing from the scope of this disclosure.

As shown in FIG. 6, the displayed physiological parameter trends includeheart rate, blood pressure, SpO2, temperature, FiO2, EtCO2, tidal volume(TV), respiration rate (RR), and positive end expiratory pressure(PEEP). The displayed machine setting trends include machine mode(herein, the machine is controlled in a volume control ventilation (VCV)mode). The displayed trends may be customized by the user, for exampleby selecting the edit button 608 and deleting displayed trends or addingtrends to be displayed (e.g., from a list of possible patient monitoringparameter trends). While each of the trends shown in FIG. 6 areformatted as trend lines, in some embodiments one or more of the patientmonitoring parameter trends may be displayed in a different format, suchas a series of bar graphs.

As explained above, the trends GUI 600 may include a timeline whenprompted. In some embodiments, the timeline may be displayed in responseto a first user input, such as a single touch input entered to thedisplay along the time points displayed above the set of trends 610.While the timeline may show respective values for each of the patientmonitoring parameters at a single point in time, it may be beneficialfor the user to view changes in the patient monitoring parameters in amore quantifiable manner (e.g., rather than having to guess at anoverall trend based on the trend lines). Accordingly, a set of timelinesmay be displayed in response to a second user input, such as twoconcurrent touch inputs made to the display at the set of trends 610(e.g., two fingers touching the display at the same time). A respectivetimeline may then be displayed at times corresponding to the location ofthe touch inputs, as shown in FIG. 7.

FIG. 7 shows a view 700 of the trends GUI 600 of FIG. 6 with twotimelines displayed on the set of trends 610. The timelines include afirst timeline 702 and a second timeline 704. First timeline 702 may bepositioned at a location corresponding to a first touch input (e.g., at08:45) and second timeline 704 may be positioned at a locationcorresponding to a second touch input (e.g., at 09:45) of two concurrenttouch inputs. The two timelines may be moved in response to a thirdtouch input, such as the two timelines being brought closer together ormoved further apart in response to concurrent touch inputs to the twotimelines followed by dragging of the timelines closer together orfurther apart.

When the two timelines are displayed as shown in FIG. 7, rather thandisplaying corresponding instantaneous values for each displayed patientmonitoring parameter (as shown in FIG. 6), an overall change in eachpatient monitoring parameter over the duration between the firsttimeline 702 and the second timeline 704 is displayed. For example, anoverall change in heart rate may be determined from 08:45 to 09:45(e.g., an increase of 20%) and displayed next to the trend line forheart rate.

As explained above with respect to FIG. 2, single-patient GUI 200includes an insights tile 302, a message tile 304, and an alarms tile306, where notifications regarding insights, messages, and alarms,respectively, specific to the patient are displayed. When an insight oralarm has been triggered, or when a message has been received, the usermay select the appropriate tile to cause the insight, message, or alarmto be displayed. FIGS. 8-10 show example views of single-patient GUI 200where the insights tile is selected, the alarm tile is selected, and themessages tile is selected, respectively.

Referring first to FIG. 8, it shows an insights view 800 ofsingle-patient GUI 200 displayed on display device 202 where theinsights tile 302 indicates that two insights have been triggered forthe patient (e.g., located in OR 2). User selection of the insights tile302 (shown schematically by hand 802) causes an insights banner 804 tobe displayed. The insights banner 804 may indicate the insight(s) thathave been triggered for the patient, such as an oxygen/medical gas flowvia the ventilator to the patient that has been greater than 6 pounds aminute for more than 10 minutes (as shown in FIG. 8). In the exampleshown in FIG. 8, the insights banner 804 is showing information relatedto a first insight. If additional insights have been triggered for thepatient, user input (e.g., a touch input swiping the insights banner)may cause the additional insight(s) to be displayed at the insightsbanner 804. Further, a visual notification of the addition insights maybe displayed, such as the two dots shown above the insights banner 804in FIG. 8.

Additionally, user selection of the insights tile 302 causes actionbuttons to be displayed, including an acknowledge button 806 and asnooze button 808. When selected, the acknowledge button 806 mayindicate to the supervisory application that the user has seen theinsight, and thus further notification of the insight via the currentsingle-patient GUI 200 may be dispensed with. When selected, the snoozebutton 808 may indicate to the supervisory application that the user hasseen the insight, but would like to be reminded of the insight againafter a threshold time period has elapsed (e.g., 10 minutes).

In some embodiments, patient monitoring information relevant to theinsight may be displayed along with the insights banner 804. In theexample shown in FIG. 8, a set of trends 810 is displayed below theinsights banner 804. The set of trends 810 includes a trend line 812 forthe oxygen/medical gas flow referenced in the insight as well as trendlines for parameters related to the oxygen/medical gas flow, shown hereas including the anesthesia phase, anesthesia concentration (e.g., Sev%), and patient oxygen saturation (e.g., O2%). Similar to the other setsof trends explained above, a timeline 814 may be displayed in responseto user input (e.g., a touch input to a selected time point of the setof trends 810).

Referring to FIG. 9, it shows an alarm view 900 of single-patient GUI200 displayed on display device 202 where the alarm tile 306 indicatesthat an alarm has been triggered for the patient (e.g., located in OR2). User selection of the alarm tile 306 (shown schematically by hand902) causes an alarm banner 904 to be displayed. The alarm banner 904may indicate the alarm(s) that have been triggered for the patient, suchas SpO2 being below a threshold value (as shown in FIG. 9). In theexample shown in FIG. 9, the alarm banner 904 is showing informationrelated to a first alarm. If additional alarms have been triggered forthe patient, user input (e.g., a touch input swiping the insights banner804) may cause the additional alarm(s) to be displayed at the alarmbanner 904.

Additionally, user selection of the alarm tile 306 causes action buttonsto be displayed, including an acknowledge button and a snooze button,similar to the acknowledge and snooze buttons presented above withrespect to FIG. 8. Also shown in FIG. 9 is a settings button 906 thatmay be displayed when the alarm tile 306 is selected. When selected, thesettings button 906 may cause display of settings/system alarms menuwhere the user may customize the alarms, e.g., delete existing alarms,add new alarms, and/or edit existing alarms.

Referring to FIG. 10, it shows a message view 1000 of single-patient GUI200 displayed on display device 202 where the message tile 304 indicatesthat a consultation for the patient (e.g., located in OR 2) has beenrequested by another care provider (e.g., a subordinate care provider orother care provider located in the room with the patient). Userselection of the message tile 304 (shown schematically by hand 1002)causes a message banner 1004 to be displayed. The message banner 1004may indicate the nature of the message that has been received, such asthe consultation being requested. In the example shown in FIG. 10, themessage banner 1004 is showing that a consultation has been requested.However, other types of messages may be received, such as SMS-based textmessages from another care provider requesting a particular type ofassistance, asking questions, sharing details of current patient status,and so forth. In such examples, the message banner 1004 may indicatethat a text message has been received from a care provider currentlycaring for that patient. Further, if additional messages have beenreceived that are related the patient, user input (e.g., a touch inputswiping the message banner) may cause the additional messages to bedisplayed at the message banner 1004.

Additionally, user selection of the message tile 304 and/or of messagebanner 1004 may cause a message thread 1006 to be displayed, wheremessages sent and received with the care provider who sent thetriggering message may be displayed. Also shown in FIG. 9 is a messageinput box 1008 where the user may enter text or voice input in order tosend a message to the requesting care provider. For example, as shown,the user may respond with an estimated amount of time for the user to beavailable for the requested consultation.

Thus, FIGS. 2-10 show various views of a single-patient GUI that may bedisplayed on a care provider device as part of the supervisoryapplication. Via the single-patient GUI, a user (such as a supervisinganesthesiologist or other supervising care provider) may view real-timepatient monitoring parameters for a specific patient, which may includephysiological parameters of the patient and/or machine settings for oneor more therapy devices being used to perform a procedure on thepatient. Further, via the single-patient GUI, the user may view trendsfor one or more patient monitoring parameters for the specific patientover time, as well as view and respond to alarms, insights, and/ormessages specific to the patient. The user may customize which patientmonitoring parameters to view, which trends to view, and which alarmsand insights are to be triggered/received for the patient. Further, theuser may select from two or more default layouts for how thesingle-patient GUI is to be configured visually and/or customize thelayout of the single-patient GUI (e.g., square tiles arranged in anarray, such as shown in FIG. 2, rectangular tiles arranged according tocategory as shown in FIG. 4A, etc.).

The supervisory application may also enable the user to viewmulti-patient GUIs where a limited amount of information is viewed for aplurality of different patients. FIGS. 11-16 show example multi-patientGUIs that may be displayed as part of the supervisory applicationaccording to embodiments of the present disclosure.

FIG. 11 shows a multi-patient GUI 1100 displayed on display device 202.Multi-patient GUI 1100 may be displayed in response to launching thesupervisory application and/or in response to selection of a back buttonfrom a single-patient GUI. Multi-patient GUI 1100 may displayinformation for each of a plurality of patients being overseen by theuser of the care provider device associated with display device 202,such as a supervising care provider, as explained above with respect toFIG. 2. As shown in FIG. 11, information for a first patient, a secondpatient, and a third patient is shown. Information for additionalpatients may be viewed by scrolling up or down. Each patient may beidentified by a patient banner, such as patient banner 1102 (showingthat information for the patient in OR 1 is being shown), patient banner1104 (showing that information for the patient in OR 2 is being shown),and patient banner 1106 (showing that information for the patient in OR3 is being shown). Each patient banner may include a forward button,such as forward button 1108, or other suitable action button that, whenselected, may cause display of the single-patient GUI for that patient.For example, if the forward button in patient banner 1104 is selected,single-patient GUI 200 may be displayed.

A limited amount of patient monitoring information is displayed for eachpatient via the multi-patient GUI 1100. For example, as shown for thefirst patient (e.g., located in OR 1), an insights tile 1110, an alarmtile 1112, and a message tile 1114 may all be displayed, similar to theinsights tile, the alarm tile, and the message tile of thesingle-patient GUI 200. However, due to the limited space available,each of the insights tile 1110, alarm tile 1112, and message tile 1114may be smaller relative to the tiles in the single-patient GUI 200. Asappreciated by alarm tile 1112, when an alarm has been triggered forthat patient, a number may be displayed in the alarm tile 1112,indicating the number of alarms that have been triggered for thatpatient. Similar numbers may be displayed in the insights tile 1110 andmessage tile 1114 when insights or messages, respectively, are triggeredor received for that patient. Further, the tile (e.g., alarm tile 1112)may have a different visual appearance when an insight, alarm, ormessage is triggered or received for the patient. For example, the tilemay change in color, become highlighted, or otherwise change in visualappearance to signify the presence of an insight, alarm, or message. Aninsights tile, an alarm tile, and a message tile may be displayed foreach patient.

The patient information that is displayed via the multi-patient GUI 1100may include a procedure timing tile, such as procedure timing tile 1116,that indicates the phase of the procedure (e.g., phase of anesthesiadelivery, such as maintenance) and the current duration of theprocedure. Further, as shown in FIG. 11, a plurality of patientmonitoring parameter tiles may be displayed for each patient, such as afirst patient monitoring parameter tile 1118 (showing heart rate for thefirst patient patient), a second patient monitoring parameter tile 1120(showing blood pressure), a third patient monitoring parameter 1122(showing SpO2), and a fourth patient monitoring parameter 1124 (shownEtCO2). In the example shown in FIG. 11, for each patient, the samepatient monitoring parameters may be displayed. The patient monitoringparameters that are displayed via the multi-patient GUI 1100 may becustomized by the user, as will be explained below.

Multi-patient GUI 1100 further includes a menu button 1126. Whenselected, menu button 1126 may cause a context menu to be displayed, viawhich various aspects of the multi-patient GUI may be adjusted. FIG. 12shows an example context menu 1200 that may be displayed on displaydevice 202, for example in response to user selection of the menu button1126. Context menu 1200 may be similar to context menu 500 of FIG. 5,and thus includes a plurality of control buttons that may triggerdifferent actions. For example, the context menu 1200 may include an addroom button 1202, an insights engine button 1204 (which may triggerdisplay of an insights GUI, as will be described in more detail belowwith respect to FIGS. 17-20), an edit rooms button 1206, and a roomlayout set of buttons 1208. The room layout set of buttons 1208 mayinclude a button for each different possible layout for how themulti-patient GUI is configured for display. For example, a first layout(e.g., corresponding to multi-patient GUI 1100) may be displayed whenthe “Default 1” button is selected and a second layout (e.g.,corresponding to multi-patient GUI 1300 described below) may bedisplayed when the “Default 2” button is selected. While not shown inFIG. 12, one or more additional layouts (which may be layouts customizedby the user) may be displayed when a “Customize” button is displayed.Additionally, context menu 1200 may include a settings button (shown atthe bottom of the context menu) that may cause a settings GUI to bedisplayed, when selected. Via the settings GUI, various settings of thesupervisory application may be adjusted, such as language, notificationsettings (e.g., sound, vibration), room set-up, add new room, and systemalarms. For example, in the system alarms page, preset alarms (e.g., forheart rate, SpO2, and blood pressure) may be turned on or off, and newalarms may be set, at least in some examples.

FIG. 12 shows a user input being entered (shown schematically by hand1210) to switch from the first layout of multi-patient GUI 1100 to asecond layout of multi-patient GUI 1300 of FIG. 13. As a result of theuser input, multi-patient GUI 1300 is displayed, as shown in FIG. 13.Multi-patient GUI 1300 may include less information for each patientthan multi-patient GUI 1100, and thus more patients may be viewed on onescreen. As shown in FIG. 13, multi-patient GUI 1300 includes a pluralityof patient banners, such as patient banner 1302 (showing thatinformation for the patient in OR 1 is being shown), patient banner 1304(showing that information for the patient in OR 2 is being shown), andpatient banner 1306 (showing that information for the patient in OR 3 isbeing shown). Each patient banner may include a forward button, such asforward button 1308, or other suitable action button that, whenselected, may cause display of the single-patient GUI for that patient.For example, if the forward button 1301 is selected, single-patient GUI200 may be displayed.

A limited amount of patient monitoring information is displayed for eachpatient via the multi-patient GUI 1300. For example, as shown for thefirst patient (e.g., located in OR 1), an insights tile 1310, an alarmtile 1312, and a message tile 1314 may all be displayed, similar to theinsights tile, the alarm tile, and the message tile of thesingle-patient GUI 200. However, due to the limited space available,each of the insights tile 1310, alarm tile 1312, and message tile 1314may be smaller relative to the tiles in the single-patient GUI 200. Asappreciated by alarm tile 1312, when an alarm has been triggered forthat patient, a number may be displayed in the alarm tile, indicatingthe number of alarms that have been triggered for that patient. Similarnumbers may be displayed in the insights tile and message tile wheninsights or messages, respectively, are triggered or received for thatpatient. Further, the tile (e.g., alarm tile 1312) may have a differentvisual appearance when an insight, alarm, or message is triggered orreceived for the patient. For example, the tile may change in color,become highlighted, or otherwise change in visual appearance to signifythe presence of an insight, alarm, or message. An insights tile, analarm tile, and a message tile may be displayed for each patient. Thepatient information that is displayed via the multi-patient GUI 1300 mayinclude a procedure timing tile, such as procedure timing tile 1316,that indicates the phase of the procedure (e.g., phase of anesthesiadelivery, such as maintenance) and the current duration of theprocedure. Multi-patient GUI 1300 also includes a menu button 1318 thatmay cause context menu 1200 to be displayed when selected.

Returning to FIG. 12, as explained above, the context menu 1200 includesan add room button 1202. Selection of the add room button 1202 causesdisplay of an add room page, such as the add room page 1400 shown inFIG. 14. As shown in FIG. 14, the add room page 1400 includes aplurality of square tiles arranged in an array, with the tilesindicating the available rooms which can be added to the multi-patientGUI 1100 or 1300. A first tile 1402 may include a new room button. Whenselected, the new room button may cause display of rooms not alreadyshown in the add room page 1400. Likewise, the add room page 1400includes a search button 1412 that may be selected to cause a search boxto be displayed so that the user may search for rooms not shown on addroom page 1400.

A second tile 1404 shows that OR 1 is available to be added to themulti-patient GUI and a third tile 1406 shows that OR 3 is already added(or has been selected to be added) to the multi-patient GUI. The secondtile 1404 includes an unchecked box 1408, signifying that OR 1 has notbeen added to the multi-patient GUI. User selection of the unchecked box1408 causes OR 1 to be added to the multi-patient GUI. The third tile1406 includes a checked box 1410, signifying that OR 3 is already addedor is chosen to be added to the multi-patient GUI. User selection of thechecked box 1410 will cause OR 3 to be removed from the multi-patientGUI. Once desired rooms have been added or removed, user selection of anadd button 1414 will save the added or removed rooms and update themulti-patient GUI accordingly. Changes to the multi-patient GUI, such asadding or removing rooms as explained above, may be saved in thesettings/configuration database of the edge device, as explained abovewith respect to FIG. 1B.

Returning again to FIG. 12, when the edit rooms button 1206 is selected,the multi-patient GUI (in the current layout) may be displayed withselectable control buttons displayed for each currently-selected patientmonitoring parameter. FIG. 15 shows an example edit rooms page 1500 thatmay be displayed in response to selection of the edit rooms button 1206.The edit rooms page 1500 includes a view similar to multi-patient GUI1100, but also includes selectable control buttons, such as button 1502,within each patient monitoring parameter tile (other than the insightstile and alarm tile, which may not be removed by the user, at least insome examples). User input to a control button may toggle that patientmonitoring parameter between being selected (and thus included in theGUI) and not selected (and thus not included in the GUI). Further,additional patient monitoring parameter(s) may be added via an addcontrol button, such as add control button 1504.

Additionally, the edit rooms page 1500 may include an edit banner 1508that may include various edit functionalities, such as adding a room,turning on a trend for a particular patient monitoring parameter,resizing a patient monitoring parameter tile, and removing a patientmonitoring parameter tile. For example, when the user selects a controlbutton, such as the control button that is within tile 1118, the “trendon,” “resize,” and “remove” buttons may become selectable. By selectingthe “trend on” button, a trend for that patient monitoring parameter maybe shown, in addition or alternative to the most-recently obtained valuefor that patient monitoring parameter. When the “resize” button isselected, the tile for that patient monitoring parameter may resized(e.g., made larger or smaller, which may also cause more or lessinformation associated with that patient monitoring parameter to bedisplayed). When the “remove” button is selected, the tile for thatpatient monitoring parameter may be removed. Once the user has madedesired changes to the patient monitoring parameters shown for eachpatient, the user may select a save button 1510, which will save andapply the changes to the multi-patient GUI.

In the example shown in FIG. 15, a touch input is being entered to theadd control button 1504 (shown schematically by hand 1506). As a result,an add tile page is displayed, via which the user may choose patientmonitoring parameter tiles to add for the selected patient/room. FIG. 16shows an example add tiles page 1600. The add tiles page 1600 mayinclude a plurality of patient monitoring parameter buttons arranged inan array. The patient monitoring parameter buttons may each beassociated with a patient monitoring parameter. For example, a firstpatient monitoring parameter button 1610 may be specific to heart rate.The patient monitoring parameter buttons may be organized and displayedby category, which may aid the user in quickly navigating through theplurality of possible patient monitoring parameters to add to the GUI.For example, as shown in FIG. 16, a circulation button 1602 has beenselected, causing patient monitoring parameters related to circulationto be displayed on the add tiles page 1600. The add tiles page 1600 alsoincludes an oxygenation button 1604 and a ventilation button 1606, whichwhen selected cause display of patient monitoring parameters related tooxygenation and ventilation, respectively. The add tiles page 1600 alsoincludes a search button 1616 that may cause a search box to bedisplayed, via which the user may enter search terms to find a desiredpatient monitoring parameter.

Each patient monitoring parameter button may include a box, such as box1612. User input to the patient monitoring parameter button may causethe associated box to become checked/selected (if not selected) orunchecked/unselected (if selected). For example, user input to button1610 (shown by hand 1614) may cause box 1612 to become checked,indicating that heart rate is being chosen to be added as a patientmonitoring parameter to be displayed on the GUI. Once the user has madedesired edits (e.g., adding desired patient monitoring parameters), anadd button 1618 may be selected, causing the selected patient monitoringparameter(s) to be added to the appropriate GUI.

While FIGS. 15 and 16 were described above as being specific to themulti-patient GUI (such as multi-patient GUI 1100), it is to beunderstood that similar edit rooms and add tiles pages may be displayedwhen customizing a single-patient GUI. For example, an edit rooms pagemay be displayed in response to user selection of edit room button 506of context menu 500, with the edit rooms page including similarfunctionality as the edit rooms page 1500 (e.g., control buttons toremove, resize, or add trends to patient monitoring parameters that arecurrently being displayed and control buttons to add patient monitoringparameter tiles).

As explained previously, the supervisory application may apply insights,which may be similar to alarms but may be based on multiple patientmonitoring parameters, may be applied conditionally, and so forth, whichmay provide a more nuanced approach to alerting care providers whenpatient condition has changed. The insights may include functions thatare applied on the received medical device data to determine a currentpatient status (not otherwise easily determined from viewing individualpatient monitoring parameters), predict a future patient status,determine a current phase or portion of a medical procedure, and otherapplications. The functions may include simple threshold-basedcomparisons, including one or more patient monitoring parameters and/orlimited by a scope, and also may include more complex models and/oralgorithms to analyze the received medical device data. As such, theinsights described herein may also be referred to as functions.

FIGS. 17-20 show example views of an insights GUI that may be displayedon a care provider device as part of supervisory application 44. Via theinsights GUI, a user may be able to define and edit insight rules to beapplied to patients being monitored by the user, search for and applyinsights created by other users, whether locally (e.g., at the samemedical facility) or globally, and view insights that have beentriggered for patients being monitored by the user, as explained below.

FIG. 17 shows a first view 1700 of an insights GUI being displayed ondisplay device 202. The insights GUI, and in some examples specificallythe first view 1700, may be displayed in response to user selection ofan insight engine button from a context menu (e.g., insights enginebutton 504 of FIG. 5 and/or insights engine button 1204 of FIG. 12) ofthe supervisory application, or other suitable user input. Via the firstview 1700, the user may be able to browse or search for public/sharedinsights. For example, the first view 1700 includes a search box 1702.The user may enter search terms into the search box 1702, and thesupervisory application may display any relevant insights in response.

The first view 1700 includes a first section of insights, referred to asthe “quick picks” section, where insights that have been developed byother users may be browsed. For example, a first insight tile 1704 isdisplayed in the quick picks section. The first insight tile 1704 mayinclude an indication of the insight rules (e.g., trigger an insight iftotal flow is greater than 6 pounds a minute for 10 minutes) for a firstinsight. The first insight tile 1704 may also include an indication ofhow many users have applied the first insight. The first view 1700 mayinclude four insight tiles displayed as part of the quick picks section,but other numbers of insight tiles are possible. Further, additionalinsight tiles created by other users may be viewed by selecting the“view all” button within the quick picks section.

The insights that are displayed as part of the quick picks section maybe generated by all users, whether locally or at other medicalfacilities. In some examples, the insights in the quick picks sectionmay be organized by popularity, such that the insights that have beenapplied by the most users may be displayed first. However, other methodsfor organizing and presenting the insights are possible, such as bypatient monitoring parameter.

The first view 1700 further includes a second insights section, referredto as a “hospital insights” section, where insights created by users atthe same medical facility may be browsed. For example, the hospitalinsights section includes a second insight tile 1706, where insightrules for a second insight are displayed, along with the number of usersapplying the insight and the author of the insight. The first view 1700may include four insight tiles displayed as part of the hospitalinsights section, but other numbers of insight tiles are possible.Further, additional insight tiles created by other users at the medicalfacility may be viewed by selecting the “view all” button within thehospital insights section.

The insights that are displayed as part of the hospital insights sectionmay be generated only by users that attend to patients at the medicalfacility where the user interacting with the first view 1700 (e.g., theuser of the care provider device associated with display device 202)attends to patients. In this way, the user may browse insights fromtrusted sources that conform to any internal standards or guidelinesapplied by the medical facility or other administrative organization. Insome examples, the insights in the hospital insights section may beorganized by popularity, by patient monitoring parameter, by date theinsight was created, etc.

The first view 1700 includes a plurality of control buttons displayedalong a bottom of the first view 1700. The control buttons include adiscover button 1708, an activity button 1710, and a my insights button1712. When the discover button 1708 is selected, the first view 1700 maydisplayed, which may enable the user to discover/search for newinsights. When the activity button 1710 is selected, a second view ofthe insights GUI may be displayed where a list of the user's selectedinsights, and in some examples alarms, that have been applied to apatient may be viewed. When the my insights button 1712 is selected, athird view of the insights GUI may be displayed where the user may add,remove, and edit insights.

FIG. 18 shows an example of a second view 1800 of the insights GUI thatmay be displayed in response to user selection of an activity button,such as activity button 1710. The second view 1800 includes the searchbox 1702, the discover button 1708, the activity button 1710, and the myinsights button 1712, similar to the first view 1700. The second viewincludes a list of insights and alarms that have been applied to one ormore patients. The insights and alarms that are listed in the secondview 1800 may include insights and alarms chosen by the user to beapplied to the patients being monitored by the user, that were appliedto a patient during the course of a procedure where the patient wasbeing monitored/treated by one or more of the medical devices describedherein. For example, a first applied insight tile 1802 is displayed inthe first view 1800. The first applied insight tile 1802 includes anindication of the rules of the insight/alarm that was applied, herein aheart rate limit high priority alarm. The tile 1802 further includes anindication of when the insight/alarm was triggered (e.g., today at14:12), on which patient (e.g., the patient in room 2), and for how longthe triggering condition persisted (e.g., for 12 seconds). The appliedinsights/alarm tiles may be organized chronologically,reverse-chronologically, or in another suitable manner.

FIG. 19 shows an example of a third view 1900 of an insights GUI thatmay be displayed in response to user selection of a my insights button(e.g., my insights button 1712). The third view 1900 includes thediscover button 1708, the activity button 1710, and the my insightsbutton 1712, similar to the first view 1700 and second view 1800. In thethird view 1900, a list of all alarms and insights saved/selected by theuser are shown, including alarms/insights that are selected to beapplied and alarms/insights that are currently not being applied. Forexample, a first tile 1902 includes an indication of the rules of thealarm/insight (e.g., SpO2 high alarm) and an indication of whichpatients that alarm/insight is be applied to (e.g., all patients). Thetile 1902 also includes an on/off button 1904 showing that thealarm/insight is on, which indicates that the alarm/insight will beapplied with patient monitoring parameters meeting the alarm/insightrules. The third view 1900 includes a second tile 1906 that includesalarm/insight rules (e.g., arterial mean pressure high alarm) and whothe alarm/insight applies to (e.g., all). The second tile 1906 includesan on/off button 1908 showing that the alarm/insight is no longer beingapplied.

If the user selects an alarm or insight listed in the third view 1900,or if the user selects an add alarm/insight button 1910, a fourth view2000 of the insights GUI may be displayed, as shown in FIG. 20. Via thefourth view 2000, aspects of the alarm/insight may be edited. Forexample, the fourth view 2000 includes an information tile 2002 for theselected insight/alarm, which indicates the insight rules (e.g., ifheart rate is greater than 150 beats/minute for 5 minutes duringmaintenance phase), priority level (e.g., level 1), and who the insightis to be applied to (e.g., all rooms). The tile 2002 includes a togglebutton 2004 that the user may move to turn the insight on (as shown) oroff. Further, the fourth view 2000 includes an edit button 2006 and adelete button 2008. When selected, the edit 2006 button may causedisplay of an edit page, where aspects of the insight may be changed.When selected, the delete button 2008 may cause the selected insight tobe removed from the user's list of insights (e.g., the insight will notbe shown in the third view 1900). In some examples, the fourth view 2000may include a share insight button 2010 that may change the privacysettings of the displayed insight from private to public when selected.For example, the insight displayed in FIG. 20 is marked as private, butselection of share insight button 2010 may switch the privacy setting topublic. Once the privacy setting is changed to public, other uses mayview and apply the insight, if desired.

The example insight shown in FIG. 20 may include a condition (heart ratebeing greater than 150 beats per minute) and two scopes, the conditionpersisting for a specified amount of time (e.g., five minutes) and thecondition occurring during a particular time of the procedure (e.g.,during maintenance phase). The user may create the example insight via anew insights view of the insights GUI. FIG. 29 shows an example newinsights view 2900 that may be displayed on display device 202 inresponse to a user request to create a new insight, such as in responseto user selection of a new insight button (e.g., button 1910 of FIG.19). Via the new insights view 2900, a user may enter a title for theinsight in a title box 2902, add a condition for the insight via acondition menu 2904, add a scope for the condition via a scope menu2906, and select a priority for the insight (e.g., low, medium, or high)via a priority menu 2908.

The condition(s) that may be added via the condition menu 2904 may beselected from a predefined set of parameters. The predefined set ofparameters may include any patient monitoring parameter available in thesystem, and thus selection of the condition menu 2904 may launch a viewthat is similar to the view shown in FIG. 16 where available patientmonitoring parameters are shown and may be selected for the condition.The predefined set of parameters may include other insights that theuser has created or selected to be applied. Once a patient monitoringparameter is selected, a threshold for that parameter may be entered.The scope for the condition may be fully user defined (e.g., the usermay enter text to define the scope) or the scope menu 2906 may includedifferent types of scopes from which the user may select (e.g., numberof minutes the condition is to persist, the phase of the procedure thecondition is to occur in, etc.). The scope menu may include a predefinedset of operators, such as “and”, “or”, “while”, and so forth, that mayallow the user to create an insight having multiple parameters and/ormultiple scopes. In doing so, the user may gain more knowledge ofpatient status than by relying on the machine-generating alarms, whichmay only track a single patient monitoring parameter.

Further, the user may select to turn on the insight via an on/off button2910 and may adjust the privacy setting of the insight, such as sharethe insight or make the insight private, via a share selection box 2912.Once the user has created the insight and set all the insightparameters, the insight may be saved by selecting the save button.

Thus, the supervisory application may allow a user, such as asupervising care provider, to oversee multiple patients at one time,from any location within a medical facility. The supervisory applicationmay present patient monitoring parameters in real-time, as well ashistorical data such as changes in patient monitoring parameters overtime, via a plurality of GUIs, as explained above. The GUIs presentedabove with respect to FIGS. 2-20 may be a first set of GUIs that aredisplayable if the user is a supervising care provider. For example,upon initially launching the supervisory application, the user may beauthenticated via a suitable authentication mechanism. Theauthentication process may include determining if the user is asupervising care provider (e.g., anesthesiologist supervising multiplenurse anesthesiologists) or if the user is a subordinate care provider(e.g., one of the nurse anesthesiologists). Once the supervisoryapplication has confirmed the identity of the user via theauthentication process, the supervisory application may access careprovider information stored in memory of a device of the hospitalnetwork (e.g., on the edge device, on a hospital operations systemdevice) or available remotely (e.g., via the MDD processing system orother cloud-based service) to determine which care providers the user issupervising (if the user is a supervising care provider) or determinewhich care provider is supervising the user (if the user is asubordinate care provider), in order to coordinate communication amongthe supervising care providers and the associated one or moresubordinate care providers. If the user is identified as a supervisingcare provider, the GUIs presented above with respect to FIGS. 2-20 maybe displayed on the user's device when prompted. However, if the user isidentified as a subordinate care provider, the GUIs presented above maynot be displayed. Instead, an in-room GUI that presents information foronly for a single patient may be displayed. As will be discussed in moredetail below with respect to FIGS. 21-23, the in-room GUI may presentreal-time patient monitoring parameters for a patient and alarmnotifications, similar to the single-patient GUIs described above. Thein-room GUI may also facilitate rapid communication between the in-room(e.g., subordinate) care provider and the supervising care provider viaa one-touch/click consultation button (which requests a consultationwith the supervising care provider), a message button that launches amessage thread with the supervising care provider, and a snapshot buttonthat captures an image of the current patient monitoring parametersbeing viewed via the in-room GUI. This image may be sent to thesupervising care provider, which may allow the supervising care providerto quickly assess patient state without having to navigate to thesupervising care provider's own single-patient GUI for that patient.

FIGS. 21-23 show various views or pages of an in-room GUI that may bedisplayed to a subordinate care provider. FIG. 21 shows a first view ofan in-room GUI 2100 being displayed on a display device 2102. Displaydevice 2102 may be associated with a care provider device, such as careprovider device 136. In-room GUI 2100 may include an identificationheader 2104 that identifies the room or patient that the GUI is showingpatient monitoring parameters for, herein room 3. The identificationheader 2104 includes a call button 2106. When selected, the call button2106 may send a request for a consultation to the care provider deviceof the care provider overseeing the user of the device on which thein-room GUI is being displayed. For example, the in-room GUI may beviewed on a care provider device (e.g., care provider device 136) by anurse anesthesiologist attending to the patient in room 3, and selectionof the call button 2106 may cause a consultation request to be sent tothe care provider device (e.g., care provider device 134) of thesupervising anesthesiologist that is supervising the nurseanesthesiologist, but who is in a different location (e.g., in adifferent room in the medical facility). The identification header 2104also includes a snapshot button 2108. When selected, the snapshot button2108 takes a snapshot (e.g., an image) of the currently-displayedin-room GUI and saves the captured image in memory, where the capturedimage can be sent to the supervising care provider and/or annotated withadditional information, as will be described in more detail below.

The in-room GUI 2100 includes an alarm tile 2110 and a procedure timingtile 2112. The alarm tile 2110 may include an indication of how manyalarms have been triggered for the patient, similar the alarm tileexplained above with respect to FIG. 9, for example. When selected, thealarm tile 2110 may cause an explanation of each triggered alarm to bedisplayed within the in-room GUI 2100, as explained above with respectto FIG. 9. The procedure timing tile 2112 may include an indication ofthe current phase of the procedure as well as the total elapsed durationof the procedure being carried out on the patient.

The in-room GUI 2100 includes a plurality of patient monitoring tiles,such as patient monitoring tile 2114 (which is displaying patient heartrate both as a representative ECG waveform and as a most-recentlydetermined value). The patient monitoring parameters that are displayedvia the in-room GUI 2100 may not be customized by the user of thein-room GUI. Rather, the patient monitoring parameters that aredisplayed in the in-room GUI 2100 may be synched with the patientmonitoring parameters that have been selected by the supervising careprovider to be displayed in the single-patient GUI for that patient. Forexample, the supervising care provider may customize a single-patientGUI for room 3, as explained above with respect to FIGS. 15 and 16. Thepatient monitoring parameters selected by the supervising care providerto be included in the single-patient GUI for room 3 may also be includedin the in-room GUI 2100. This may include the inclusion of the patientmonitoring parameters and may also include whether the value(s) for eachpatient monitoring parameter is viewed as a trend/waveform and/ormost-recently determined value and the location of each patientmonitoring parameter tile. In this way, the information and the visualappearance of the in-room GUI may mimic the corresponding single-patientGUI.

The in-room GUI 2100 includes a plurality of control buttons that may bedisplayed along a tile at the bottom of the in-room GUI 2100 or otherlocation. The plurality of control buttons includes a room view button2116, a message view button 2118, and a snapshot view button 2120. Whenselected, the room view button 2116 causes the first view of the in-roomGUI to be displayed (e.g., as shown in FIG. 21). The message view button2118, when selected, causes display of a message view where a messagethread between the subordinate care provider and supervising careprovider may be viewed and carried out, which is shown in FIG. 22 anddescribed in more detail below. The snapshot view button 2120, whenselected, causes display of a snapshot view where snapshots of thein-room GUI that have been captured via the snapshot button may bedisplayed and annotated, as shown in FIG. 23 and described in moredetail below.

FIG. 22 shows a message view 2200 of the in-room GUI 2100 that may bedisplayed when the message view button 2118 is selected. The messageview 2200 includes the identification header 2104, including the callbutton 2106 and the snapshot button 2108. The message view 2200 alsoincludes the room view button 2116, the message view button 2118, andthe snapshot view button 2120.

The message view 2200 includes a message thread 2202 occurring betweenthe user of the in-room GUI 2100 (e.g., the subordinate care provider)and the corresponding supervising care provider. The message thread 2202may include text messages (e.g., the message stating “cannot resolvealarm, need help!” read at 16:26). When desired, the user may send asnapshot of a view of the in-room GUI, such as a snapshot of the firstview shown in FIG. 22. Thus, as shown, the message thread 2202 includesa snapshot 2204 of the first view of the in-room GUI 2100 that includesthe patient monitoring parameters. In this way, when the subordinatecare provider requests assistance or advice from the supervising careprovider, the subordinate care provider may send a message (by enteringtext into message box 2206 or by entering voice input) explaining theissue the subordinate care provider is having (e.g., an alarm thatcannot be resolved), and if the subordinate care provider thinks it maybe helpful, the subordinate care provider may send a snapshot of thevalues of the patient monitoring parameters displayed via the in-roomGUI. The supervising care provider may then be able to assess currentpatient state, machine settings, and/or other relevant information(e.g., additional information conveyed by the subordinate care providervia the message thread) in a single view, without having to navigate toother GUIs or pages. The supervising care provider may then send adviceor instructions to the subordinate care provider via the message thread.

The supervising care provider may view the message thread 2202 on thesupervising care provider's device. For example, as shown in FIG. 4A,the single-patient GUI 200 may include a message tile 304. When amessage is received from a subordinate care provider that is specific tothe patient of the single-patient GUI 200, the message tile 304 mayinclude an indication that a message is available. When the message tile304 is selected, the message thread between the supervising careprovider and the subordinate care provider may displayed, for example ina manner similar to the message thread shown in FIG. 10.

FIG. 23 shows a snapshot view 2300 of the in-room GUI 2100 that may bedisplayed when the snapshot view button 2120 is selected. The snapshotview 2300 includes the identification header 2104, including the callbutton 2106 and a format button 2301. The snapshot view 2300 alsoincludes the room view button 2116, the message view button 2118, andthe snapshot view button 2120.

The snapshot view 2300 includes a list of snapshots 2302 captured by theuser for the patient (e.g., of the in-room GUI for room 3) displayed ina timeline format. Each snapshot included in the list of snapshots 2302includes a captured image 2304 (e.g., the snapshot) and correspondinginformation 2306. The corresponding information 2306 may include thetiming and the phase of the procedure when the snapshot was taken (e.g.,15:23 induction), how many alarms were triggered for the patient whenthe snapshot was taken (e.g., 3 alarms), and notes as entered by theuser. The notes may be entered and/or edited by selecting a notes button2308. In the example shown in FIG. 23, the notes entered by the userincludes an indication that the patient had been intubated for 15minutes when the snapshot was taken. In some examples, user selection ofthe alarms shown in the corresponding information 2306 may triggerdisplay of information pertaining to the alarms that were triggered forthe patient at the time the snapshot was taken. Further, the capturedimages, such as captured image 2304, shown in the snapshot view 2302 maybe zoomed out/miniaturized images so that multiple images may be viewedon one screen. While this may facilitate quick viewing of each snapshot,it may be difficult for the values of the patient monitoring parametersin each snapshot to be viewed. Thus, at least in some examples, eachcaptured image may be viewed in a separate page when that image isselected. The snapshots and associated information shown in FIG. 23 arearranged chronologically into a timeline. However, selection of theformat button 2301 may cause the snapshot view to be displayed in adifferent format, for example in a phases format where the snapshots fora given patient and procedure are arranged by procedure phase, such asby anesthesia phase. The phases format may include a similar formatbutton that, when selected, causes the timeline format of the snapshotsto be displayed.

FIG. 24 is a flow chart illustrating an example method for displayingsupervising graphical user interfaces generated via a supervisoryapplication on a display device associated with a care provider device.Method 2400 may be implemented by a care provider device (such as careprovider device 134) being used by a supervising care provider incombination with an edge device connected to the care provider device(e.g., edge device 20), a cloud in communication with the edge deviceand/or care provider device (e.g., MDD processing system 12), or anyappropriate combination thereof.

At 2402, a request to launch the supervisory application is received.The request to launch the supervisory application may be received viauser input, such as a user of the care provider device selecting asupervisory application icon displayed on a home page or other locationof the display device associated with the care provider device. Upon therequest to launch the supervisory application being received, amulti-patient GUI is output for display on the display device, asindicated at 2404. In some examples, the multi-patient GUI may be thedefault page for the supervisory application, such that any time thesupervisory application is launched from an unlaunched state, themulti-patient GUI is displayed. Further, in some examples, prior todisplaying the multi-patient GUI and after the request to launch thesupervisory application is received, an authentication/log-in page maybe displayed, via which the user may enter log-in information via textinput, via a captured image (e.g., facial recognition), via afingerprint, or other suitable mechanism for entering credentials forauthentication. Once the user is authenticated, the multi-patient GUImay be launched. In still further examples, if the user has not alreadyset up their view of the supervisory application, a set-up page may bedisplayed after user authentication, via which the user may select whichrooms/patients to display in the multi-patient GUI.

As an example, after launching the supervisory application andauthenticating the user, the supervisory application may display aninitial set-up page, which may include a menu button (similar to menubutton 1126 of FIG. 11) that when selected causes display of a contextmenu that includes an add room button, similar to the context menu 1200and the add room button 1202 of FIG. 12. When the user selects the addroom button, an add rooms page may be displayed, similar to the addrooms view 1400 of FIG. 14. The user may then select whichrooms/patients are to be added to the multi-patient GUI. In someexamples, the initial set-up page may include an add room box or othermore direct mechanism that when selected by the user causes display ofthe add rooms view.

The multi-patient GUI may include limited information for each of aplurality of patients. For example, the multi-patient GUI 1100 of FIG.11 includes, for each selected room/patient, a subset of all availablepatient monitoring parameters that may be viewed for that patient (e.g.,the patient monitoring parameter tiles 1118, 1120, 1122, and 1124) andone or more alert and timing tiles, such as an alarm tile (e.g., alarmtile 1112), a message tile (e.g., message tile 1114), an insights tile(e.g., insights tile 1110), and a procedure timing tile (e.g., proceduretiming tile 1116). The layout of the multi-patient GUI and/or the roomsthat are displayed as part of the multi-patient GUI may be adjusted whenrequested, as indicated at 2406. For example, the multi-patient GUI 1100of FIG. 11 may be a first layout for the multi-patient GUI, and the usermay select to switch to a different layout, such as the layout of themulti-patient GUI 1300 of FIG. 13, by selecting the appropriate layoutfrom the context menu. The second layout shown in FIG. 13 may includethe alert and timing tiles, but may not include any patient monitoringparameter tiles. Further, the user may add or remove rooms/patients fromthe multi-patient GUI by selecting the add rooms button of the contextmenu (e.g., button 1202 of menu 1200), which may launch the add roomsview 1400. As explained above, via the add rooms view, the user may addrooms/patients to the multi-patient GUI and may also removerooms/patients from the multi-patient GUI.

In some examples, the user may further customize the layout of themulti-patient GUI by adjusting the information presented via themulti-patient GUI, as indicated at 2408. As explained previously, themulti-patient GUI may display, via the subset of patient monitoringparameters, real-time determined values for each of the patientmonitoring parameters, as received from one or more medical devices(e.g., the medical devices 16 of FIG. 1A, which may includephysiological monitoring devices 16 a as well as patient therapy devices16 b, e.g., anesthesia delivery machines) and streamed from anintermediary device (e.g., streamed from the streaming server 114 of theedge device 20). The user may customize which patient monitoringparameters are included in the multi-patient GUI by selecting an editrooms button of the context menu, such as edit rooms button 1206 of menu1200, which may cause an edit rooms view to be displayed, such as theedit rooms page 1500 of FIG. 15. Via the edit rooms view, the user mayadd or remove patient monitoring parameters to the multi-patient GUI ina patient/room-specific manner, select to view the patient monitoringparameters as trends or single values, and/or resize the tiles for thepatient monitoring parameters.

At 2410, a single-patient GUI may be output for display when requested.The single-patient GUI may include notifications/alerts and/or patientmonitoring parameters for a single patient, rather than multiplepatients. Example single-patient GUIs are shown in FIGS. 2 and 4A andexplained above. The single-patient GUI may be output for display inresponse to a user request, such as the user selecting a room/patientfrom the multi-patient GUI. For example, referring to FIG. 13, userselection of the forward button 1301 may cause single-patient GUI 200 tobe displayed. The single-patient GUI may include more information forthe selected patient than the corresponding information in themulti-patient GUI for that patient, thus allowing the care provider todrill down to a more-detailed for a single patient when desired.

The single-patient GUI, similar to the multi-patient GUI, may becustomized by the user to have a desired layout, display desiredinformation, and so forth. Thus, as indicated at 2412, the layout of thesingle-patient GUI may be adjusted when requested. The layout may beadjusted similarly to the layout adjustment of the multi-patient GUI,e.g., in response to user selection of a desired layout from a contextmenu (e.g., context menu 500 of FIG. 5). Further, as indicated at 2414,the information presented via the single-patient GUI may be adjustedwhen requested. Similar to the multi-patient GUI, the single-patient GUImay be adjusted via an edit rooms view and/or add tiles view similar tothe edit rooms page 1500 of FIG. 15 and add tiles page 1600 of FIG. 16.

In some examples, a user may request to add a patient monitoringparameter to the single-patient GUI, remove a patient monitoringparameter from the single-patient GUI, request to view a patientmonitoring parameter as a value or as a trend in a tile, request to viewthe result of an insight as a tile on the single-patient GUI, or performanother action that may cause the layout of the single-patient GUI tochange. In such examples, one or more of the remaining patientmonitoring parameter tiles on the single-patient GUI may be adjusted inresponse to the user action. For example, one or more patient monitoringparameter tiles may be moved, resized, scaled, etc., to accommodate anewly added tile, take up space left by a removed tile, and so forth.The adjustments may be performed automatically by the supervisoryapplication in some examples. When a tile is resized, differentinformation may be displayed in a smaller tile versus a larger tile. Asan example, if a user chooses to view a patient monitoring parameter asa trend rather than or in addition to a value, that patient monitoringparameter tile may be increased in size and more information may bedisplayed. If a patient monitoring parameter tile is reduced in size,less information may be shown. Further, each patient monitoringparameter tile may have seven states: a numerical state, an edit state,a selected state, a trend state, a waveform state, an alarm state, and adrag state, which may be displayed according to user input. Thenumerical state may show only a value for that parameter, the edit statemay include a checkbox allowing the user to select or deselect theparameter (thus adding or deleing the tile), the selected state mayinclude a visual indication that the tile has been selected by the user(e.g., highlighting), the trend state may include a trend of theparameter over time (e.g., a trend line), the waveform state may showthe parameter as a waveform rather than value (e.g., ECG waveform), thealarm state may highlight the value of the parameter if an alarmcondition is reached, and the drag state may include the tile having avisual appearance indicating the user is dragging the tile (e.g., to anew location), such as the tile changing color or transparency.

As explained previously, the patient monitoring parameters that may bedisplayed via the single-patient GUI may include physiologicalparameters such as measured or inferred heart rate, blood pressure,temperature, and so forth. The patient monitoring parameters may furtherinclude, at least in some examples, machine settings for one or moretherapy devices being used to carry out a procedure on the patient (orbeing used in support of the procedure being carried out on thepatient), such as settings for an anesthesia delivery machine. Thesettings may include anesthetic agent concentration, medical gas flowrate, ventilator settings, and so forth. While viewing these settingsmay be helpful for a user who is located in a different location thanthe patient (e.g., attending to another patient), the supervisoryapplication may also allow for the user to directly adjust one or moremachine settings remotely, without having to actually be in the roomwhere the therapy device is located. Accordingly, as indicated at 2415,a command to adjust one or more machine parameters may be sent to theedge device and/or MDD processing system, when requested. FIG. 28 showsa non-limiting example of how a user may command a change to a machineparameter via the single-patient GUI. FIG. 28 shows an adjustment view2800 of the single-patient GUI 200 of FIG. 2, which includes the thirdtile 214 displaying anesthetic agent type and concentration. Userselection of the third tile 214 may cause an adjustment box 2802 to bedisplayed. The adjustment box 2802 may include the selected machineparameter (e.g., sevoflurane concentration) and an adjustment mechanism2804, which herein includes an up arrow and a down arrow. User input tothe adjustment mechanism may cause the sevoflurane concentration toincrease or decrease, which may be reflected in the sevofluraneconcentration displayed in the adjustment box 2802. Once the user hasadjusted the concentration to a desired concentration, the user may savethe adjusted concentration by selecting a save button, for example, ormay exit the adjustment box 2802 without adjusting the concentration byselecting a cancel button, for example. If the user has adjusted theconcentration and selected the save button, the supervisory applicationmay generate and send a command to the edge device and/or MDD processingsystem to adjust the sevoflurane concentration to the commandedconcentration. The therapy device (e.g., anesthesia delivery machine)may then receive the command and automatically change the sevofluraneconcentration.

Returning to FIG. 24, the method may include, at 2416, outputting atrends GUI for display when requested. The trends GUI may include trendsin selected patient monitoring parameters over time. FIG. 6 shows anexample trends GUI, where each trend is visualized as a trend line overthe same time duration (e.g., 10 minutes, 30 minutes, or the entirecase). The trends GUI may be displayed in response to user selection ofa trends button of a single-patient GUI context menu, such as trendsbutton 502 of menu 500. In other examples, the trends GUI may bedisplayed in response to user selection of a trends icon displayed onthe single-patient GUI, such as trends icon 474 of FIG. 4D. The timerange of the patient monitoring parameter values displayed in the trendsGUI may be adjusted when requested, as indicated at 2418. For example,the trends GUI may include a plurality of buttons each corresponding toa different time range, and user selection of one of the buttons maycause the time range of the displayed trends to change. Further, as alsoindicated at 2418, the trends GUI may show a quantified change inpatient monitoring/medical device data over a specified time period whenrequested. The quantified change may include an overall percent changebetween two specified time points, as shown in FIG. 7, which may berequested in response to user input (e.g., a concurrent two touch inputto the trends GUI). The trends of the patient monitoring parameterspresented via the trends GUI may be adjusted when requested, asindicated at 2420. For example, the trends GUI may include an editbutton, such as edit button 608, that causes a trend edit page to bedisplayed. Via the trend edit page, patient monitoring parameters may beadded or removed from the trends GUI. Further, the relative location ofeach trend on the trends GUI (e.g., the order in which the trends arepresented) may be adjusted via the trend edit page.

At 2422, an insights GUI may be output for display when requested. Theinsights GUI may present insights, which are similar to threshold-basedalarms but may be based on more parameters, have limitations on when theinsights are applied, and other factors that may make the insights morenuanced and less binary than threshold-based alarms. The insights GUImay be output for display in response to a user request, such as a userselection of an insight engine button from a context menu (e.g.,selection of insights engine button 1204 of menu 1200) or other suitableuser input. As indicated at 2424, outputting the insights GUI mayinclude displaying a searchable page(s) of local and/or global insights,generated by other users, when requested. FIG. 17 shows an example of asearchable page of the insights GUI, where insights generated by otherusers at the medical facility where the user is employed (e.g., thelocal insights) may be displayed, browsed, and/or searched, and whereinsights generated by other users at other medical facilities (e.g., theglobal insights) may be displayed, browsed, and/or searched. The usermay select one or more insights to be applied to the user'spatients/rooms. As indicated at 2426, outputting the insights GUI mayinclude creating, saving, and/or sharing insights when requested. Forexample, FIG. 19 shows a “my insights” view of the insights GUI wherethe user may view all insights saved and/or created by the user. When aninsight is selected, an insight edit page may be displayed, where theuser may turn on or off an insight or edit the rules for the insight. Auser may create an insight, such as via the new insights view shown inFIG. 29. Further, an insight may be shared in response to user request(e.g., via selection of a share insight button, such as button 2010 ofFIG. 20). When an insight is shared, the privacy setting of the insightmay be adjusted to allow other users to view and apply the insight. Thismay include the insight being sent to another device and/or the cloud,where other users may access the insight. Method 2400 then returns.

FIG. 25 is a flow chart illustrating an example method 2500 forgenerating and outputting notifications via the supervisory application.The notifications that are output via the method 2500 of FIG. 25 may beoutput on a display device associated with a care provider device.Method 2400 may be implemented by a care provider device (such as careprovider device 134) in combination with an edge device connected to thecare provider device (e.g., edge device 20), a cloud in communicationwith the edge device and/or care provider device (e.g., MDD processingsystem 12), or any appropriate combination thereof.

At 2502, medical device data is received. The medical device data may bereceived from one or more medical devices, such as the medical devices16 of FIG. 1A. The medical device data may be received by a dataingestion module of the edge device, for example, and in some examplesmay be processed by a stream processing module of the edge device, asexplained above with respect to FIG. 1B. At 2504, alarm and/or insightrules are applied to the received medical device data. For example, themedical device data that is received may be supplied to a rules engineand/or an inference engine of the edge device, which may apply insightrules in order to determine if the received medical device datasatisfies any of the saved insight rules. The insight rules may includea plurality of sets of insight rules with each set of insight rulesincluding a condition and a scope of the condition. For example, thecondition may include a specified patient monitoring parameter and acondition relative to a threshold for that patient monitoring parameter(e.g., heart rate being greater than 150 beats per minute) and the scopemay include a duration of the condition and/or procedure phase in whichthe condition is to occur in order to trigger the insight, such as forfive minutes and/or during maintenance phase of anesthesia delivery.Each set of alarm rules and each set of insight rules may also includean indication of which patient(s) the rules are applicable to and mayalso include an indication of which user(s) of the supervisoryapplication should receive a notification if the alarm rules or insightrules are satisfied.

The alarm rules may include a plurality of sets of alarm rules, witheach set of alarm rules including a specified patient monitoringparameter (e.g., heart rate) meeting a condition relative to a threshold(e.g., being greater than 150 beats per minute). In some examples, thealarms described herein may be generated by individual medical devicesand sent to the edge device, which then outputs the alarm to theappropriate care provider device (as explained below). In such cases,the only alarm rules that may be applied by the supervisory applicationmay include whether a user has chosen to receive a particular alarm orhas chosen to not be notified of a particular alarm.

At 2506, method 2500 includes determining if the received medical devicedata satisfies the alarm rules and/or the insight rules, such that analarm or an insight is triggered. For example, if medical device dataspecific to a first patient indicates that the heart rate of the patientis greater than 150 beats per minute, and if the rules engine includes aset of alarm rules indicating that an alarm should be output if thefirst patient's heart rate is greater than 150 beats per minute, thenthe medical device data satisfies that set of alarm rules. If no alarmor insight rules have been triggered, method 2500 loops back to 2502 andcontinues to receive medical device data and apply the alarm and/orinsight rules to the received data.

If the received medical device data satisfies at least one set of alarmrules or one set of insight rules, method 2500 proceeds to 2508 toautomatically generate a notification based on the satisfied rules.Generating the notification may include, as indicated at 2510,generating a notification that includes an alarm of a change in patientstate. If a set of alarm rules is satisfied, an alarm may be generated.The alarm may include an indication of which alarm rules were satisfied,the patient the alarm is for, the user(s) who should receive the alarm,and/or the time the alarm was triggered. Further, generating thenotification may include, as indicated at 2512, generating anotification that includes an insight into a change in patient state. Ifa set of insight rules is satisfied, an insight notification may begenerated. The insight notification may include an indication of whichinsight rules were satisfied, the patient the insight is specific to,the user(s) who should receive the insight notification, and/or the timethe insight was triggered. In some examples, the insight notificationmay include processed data, a prediction of future patient state, adetermination of current patient state or procedure phase, or othernon-alert result. In such examples, the result of the insight may bedisplayed as a tile on a single-patient GUI and/or multi-patient GUIduring all conditions.

At 2514, the notification is output for display. In some examples, thenotification may be generated by the edge device and sent to theappropriate care provider device directly (e.g., via a hospital networkcommunicatively coupling the edge device and the care provider device)or indirectly (e.g., via cloud-based service). When the care providerdevice receives the notification, the care provider device may displaythe notification as a tile in a multi-patient GUI and/or asingle-patient GUI, as indicated at 2516. For example, as shown in FIG.9, a brief notification of an alarm may be displayed in an alarm tile(e.g., tile 306) and a more detailed notification of the alarm may bedisplayed when requested by the user (e.g., as the alarm banner 904). Insome examples, as indicated at 2518, the notification is pushed to thecare provider device (e.g., via the cloud-based service), even when thesupervisory application is in an unlaunched state on the care providerdevice. In such an example, when the supervisory application is notlaunched on the care provider device, the care provider device mayoutput the notification for display on a notification page, a home page,and/or a sleep page of the care provider device.

At 2520, an action menu including selectable control buttons may beoutput for display when requested. The action menu may be displayed whenan alarm or insight tile of a multi-patient or single-patient GUI isselected, such as the acknowledge button 806 and snooze button 808 ofFIG. 8 that are displayed in response to user selection of the insightstile 302. At 2522, an action dictated by the selected control button maybe performed when requested. For example, if the user selects the snoozebutton, the notification of the triggered alarm or insight may be outputagain after a predetermined amount of time, such as 10 minutes.

At 2524, the notification settings for a specific user (and hence theuser's care provider device) may be adjusted when requested. Forexample, if a settings button is selected (e.g., button 906 of FIG. 9),an alarms setting page may be displayed where saved alarms may be turnedon, turned off, or removed, and where new alarms may be added. Inanother example, via input to a displayed insight in a “my insights”view of an insights GUI of the supervisory application, an edit insightpage may be displayed (e.g., as shown in FIG. 20) where saved insightsmay be turned on, turned off, edited, or deleted, and where new insightsmay be created. In a still further example, insights created by otherusers may be searched or browsed via a “discovery” view of the insightsGUI (as shown in FIG. 17), and any selected insights from the discoveryview may be saved to be applied for that user. Method 2500 then returns.

FIG. 26 is a flow chart illustrating an example method 2600 fordisplaying in-room graphical user interfaces generated via thesupervisory application on a display device associated with a careprovider device. Method 2600 may be implemented by a care providerdevice (such as care provider device 136) being used by a subordinatecare provider in combination with an edge device connected to the careprovider device (e.g., edge device 20), a cloud in communication withthe edge device and/or care provider device (e.g., MDD processing system12), or any appropriate combination thereof.

At 2602, a request to launch an in-room GUI of the supervisoryapplication is received. The request to launch the in-room GUI of thesupervisory application may be received via user input, such as a userof the care provider device selecting a supervisory application icondisplayed on a home page or other location of the display deviceassociated with the care provider device. Upon the request to launch thein-room GUI of the supervisory application being received, an in-roomGUI is output for display on the display device, as indicated at 2604.FIG. 21 shows an example of an in-room GUI.

In some examples, prior to displaying the in-room GUI and after therequest to launch the in-room GUI is received, an authentication/log-inpage may be displayed, via which the user may enter log-in informationvia text input, via a captured image (e.g., facial recognition), via afingerprint, or other suitable mechanism for entering credentials forauthentication. Once the user is authenticated, the in-room GUI may belaunched. The in-room GUI may be displayed in response to determiningthat the user requesting to launch the supervisory application is asubordinate care provider, or a care provider that is otherwiseoverseeing only a single patient at a time and/or is intended to belocated in a single room over the course of a patient procedure.Further, in some examples, the edge device may include a registrycomponent that dynamically maintains the location (room, unit,department) and patient association for each streaming device datasession (e.g., each time a care provider device launches the supervisoryapplication). The supervisory application may determine, via theregistry, which care providers are in which rooms, and launch theappropriate in-room GUI based on the location of the care providerdevices. The care providers are assigned to a department/unit. The userof the supervisory application will know which patient is currently inthe given operating room, and hence is able to associate a given patientto the streaming data provided by the operating room, at any given pointof time.

Outputting the in-room GUI for display may include outputting an in-roomGUI having a layout that is synched with the layout of the correspondingsupervising GUI, as indicated at 2606. For example, the in-room GUI maybe displayed on a display device of a care provider device that is beingused by/associated with a subordinate care provider that is beingoverseen by a supervising care provider, where the subordinate careprovider and supervising care provider are each attending to the samepatient. The supervising care provider may select/customize a layout fora single-patient GUI for the patient, as explained above with respect toFIGS. 2, 4A, and 24, for example. The layout of the in-room GUI for thepatient may match the layout of the single-patient GUI, at least withrespect to the patient monitoring parameters that are displayed. In someexamples, the user of the in-room GUI may not be able to adjust thelayout of the in-room GUI, and may not be able to adjust which patientmonitoring parameters are displayed via the in-room GUI. By synching theview of the in-room GUI with that of the corresponding single-patientGUI, the supervising care provider and subordinate care provider mayview the same information in the same format, which may ensure that thecare providers are able to properly coordinate care of the patient andmay prevent errors or miscommunication due to the care providers viewingdifferent patient monitoring parameters. However, in other examples, theinformation presented via the in-room GUI may be adjusted whenrequested, as indicated at 2608, such as via an edit function of thein-room GUI.

At 2610, a consult request may be output when requested. The consultrequest may be a quick, one-input mechanism for the subordinate careprovider to request that the supervising care provider come to the roomwhere the subordinate care provider is attending to the patient. Theconsult request may be requested by user selection of a call button,such as call button 2106 of FIG. 21. When a consult is requested, anotification may be output to the supervising care provider's device anddisplayed as a notification in a message tile of the single-patient GUIfor the patient or a multi-patient GUI and/or pushed to the supervisingcare provider's device, similar to the way in which an alarm or insightnotification is delivered to a care provider device.

At 2612, a snapshot of the display screen may be taken and anyassociated user input may be saved with the snapshot, when requested. Asnapshot may include an image of what is displayed on the display deviceat the time the snapshot request is received, which may include thecurrent values for the patient monitoring parameters being presented viathe in-room GUI. The snapshot may be taken in response to user selectionof a snapshot button on the in-room GUI, such as the snapshot button2108 of FIG. 21. The snapshot may be saved in a snapshot view of thein-room GUI, such as the snapshot view 2300 of FIG. 23. The snapshot maybe saved with relevant patient information, such as procedure phase andtiming, number of triggered alarms, etc., as well as information inputby the user of the in-room GUI. The snapshot view may be displayed whenrequested, as indicated at 2614, such as in response to user selectionof a snapshot view button of the in-room GUI (e.g., button 2120 of FIG.21).

At 2616, a message view may be displayed when requested, such as themessage view 2200 shown in FIG. 22. The message view may be displayed inresponse to user selection of a message view button of the in-room GUI,such as button 2118. In the message view, a message thread between theuser of the in-room GUI (e.g., the subordinate care provider) and thesupervising care provider may be displayed. Further, as indicated at2616, a message may be sent to the supervising care provider's devicewhen prompted. For example, the user of the in-room GUI may enter textor voice input that may be formatted into a text message and sent to thesupervising care provider's device. The user may also send rich-mediabased messages, such as a snapshot. When the message is received at thesupervising care provider's device, the single-patient GUI ormulti-patient GUI may include an indication of the received message in amessage tile (e.g., tile 304) and when the supervising care providerselects the message tile, the message thread, including the receivedmessage, may be displayed on the supervising care provider's device(e.g., as shown in FIG. 9). Further, similar to the alarm and insightnotifications, the message notification may be pushed to the supervisingcare provider's device even when the supervisory application on thesupervising care provider's device is in an unlaunched state. Method2600 then returns.

FIG. 27 is a flow chart illustrating an example method 2700 for asupervisory application. Method 2700 may be implemented by an edgedevice connected to the care provider device (e.g., edge device 20), acloud in communication with the edge device and/or care provider device(e.g., MDD processing system 12), a care provider device (such as careprovider device 134), or any appropriate combination thereof.

At 2702, medical device data from a plurality of medical devices isreceived. The medical device data may be received from one or moremedical devices, such as the medical devices 16 of FIG. 1A. The medicaldevice data may be received by a data ingestion module of the edgedevice, for example, and in some examples may be processed by a streamprocessing module of the edge device, as explained above with respect toFIG. 1B. Additionally or alternatively, the medical device data may besent to a cloud-based device, such as the MDD processing system 12 ofFIG. 1A, where the medical device data may be ingested by an ingestionmodule (e.g., high speed ingestion module 22).

At 2704, the medical device data may be processed to generate trendgraphs and the trend graphs are stored in a database. For example, eachstream of medical device data may be stored, at least temporarily, as atrend graph (which may be a line graph, a series of bar graphs, oranother suitable representation of data values over time) in a datastorage location, such as data storage 104 of FIG. 1B and/or operationcase storage 30 of FIG. 1A.

At 2706, medical device data values and/or trend graphs are output whenrequested. For example, when a supervisory application (such assupervisory application 44) is launched on a care provider device (suchas care provider device 134), a single-patient GUI (e.g., single patientGUI 200 of FIG. 2), a multi-patient GUI (e.g. multi-patient GUI 1100 ofFIG. 11 or multi-patient GUI 1300 of FIG. 13), or an in-room GUI (suchas in-room GUI 2100 of FIG. 21) may be displayed on a display of thecare provider device. When one of these GUIs is displayed, thesupervisory application may stream real-time medical device data valuesto the care provider device, via a streaming server such as streamingserver 114 of FIG. 1B. In another example, a trends GUI may be displayedon the display of the care provider device, and selectedassembled/stored trend graphs may be output to the care provider deviceto be displayed as part of the trends GUI. In a still further example,when the single-patient GUI is displayed on the display of the careprovider device, user selection of a patient monitoring parameter tilemay cause display of a trend graph for that patient monitoring parameterand/or additional trend graphs of related patient monitoring parameters,and the selected assembled/stored trend graphs may be output to the careprovider device to be displayed as part of the single-patient GUI.

At 2708, received functions are stored and selected stored functions areoutput when requested. The received functions may be received from thecare provider device, for example in response to user-creation of afunction (e.g., an insight) via an insights GUI (e.g., insights GUI1700) displayed on the display of the care provider device. Functionsmay be created via other mechanisms, and may include models, algorithms,or other routines to process the medical device data from one or moremedical devices and produce a result based on the medical device data.Functions may be received by other care provider devices at one or moremedical facilities. The received functions may be stored at the edgedevice and/or on the MDD processing system. Further, when a user createsa function, that function may be shared with other users in response toa request from the user. Thus, if a request to share a function isreceived, that function may be output to a different storage location(e.g., the rules defining the insight may be sent from the edge deviceto the MDD processing system or other cloud-based service). In otherexamples, such as when all functions are stored on the cloud, thefunction may not be output to a different location when shared, but theprivacy setting of the function may be changed to allow the function tobe shared with other users.

At 2710, the result of a user-selected function is displayed as a tilein a GUI, such as a single-patient GUI, when requested. For example, auser may select to apply a function for a specific patient or room, suchas by selecting a function created by another user via the insights GUI1700 or by selecting to apply a function created by the user, forexample by generating a function via the new insights view 2900 andselecting to apply that function. The user-selected function may producea transient result, such as a notification that is only triggered when acondition and a scope of the condition are met by the medical devicedata for the patient. As another example, the user-selected function mayproduce a persistent result that may generated under some or all of theduration of the patient monitoring for the patient, such as adetermination of the anesthesia phase or an indication of a determinedcurrent patient state, such as a sepsis risk. In the example of thefunction that produces a sepsis risk result, the sepsis risk result maybe on a scale of 1-10, classified as low, medium, or high, or anotherrepresentation of the risk, and the representation of the risk may bedetermined and output at any time over the course of the patientmonitoring. If the function produces a transient result, the result ofthe function may be displayed as a tile (e.g., as an insights tile) in asingle-patient GUI specific to the patient or room and/or in amulti-patient GUI only in response to the rules of the function (e.g.,the condition/scope) being met. If the function produces a persistentresult, the result from the function may be displayed as a tile in thesingle-patient GUI for the patient in response to a user request todisplay the tile, and may only be removed from the GUI in response to auser request to remove the tile.

At 2712, the result of a user-selected function is input into a seconduser-selected function, when requested. As explained above, somefunctions may include the output of another function as an input, alongwith the medical device data. If a second user-selected functionincludes the result of a first user-selected function as an input, theresult of the first user-selected function may be determined and thensupplied to the second user-selected function. For example, a firstfunction may produce current anesthesia phase as a result and a secondfunction may include a notification being output as a result when heartrate is greater than a threshold during maintenance phase of anesthesia.The result of the first function may be used by the second function todetermine the result of the second function along with the receivedmedical device data (e.g., the anesthesia phase may be analyzed alongwith the heart rate as determined from a medical device monitoring apatient to determine if a notification should be output). As anotherexample, a first function may produce sepsis risk as a result and asecond function may include a notification being output as a result whenheart rate is greater than a first threshold and when sepsis risk isgreater than a second threshold. The result of the first function may beused by the second function to determine the result of the secondfunction along with the received medical device data (e.g., the sepsisrisk as determined by the first function may be analyzed along with theheart rate as determined from a medical device monitoring a patient todetermine if a notification should be output).

At 2714, in some examples, the result of a user-selected function isbased on medical device data from at least two different medicaldevices, and the respective patient monitoring values or trends fromeach of the two different medical devices may be displayed as respectivetiles on a single-patient GUI, and in some examples, the result of theuser-selected function is displayed as a separate tile on thesingle-patient GUI. For example, a function that produces a sepsis riskvalue (e.g., on a scale of 1-10) may determine the sepsis risk valuebased on, among other parameters, heart rate and body temperature. Heartrate may be determined from first medical device data output by a firstmedical device (e.g., a heart rate monitor) and body temperature may bedetermined from second medical device data output by a second medicaldevice (e.g., a temperature sensor). The heart rate may be displayed ina first patient monitoring parameter tile on a single-patient GUI, thebody temperature may be displayed in a second patient monitoringparameter tile on the single-patient GUI, and the sepsis risk may bedisplayed as a third tile on the single-patient GUI.

As another example, a function that produces a notification when achange in heart rate over a specified duration is above a thresholdchange and when body temperature is above threshold temperature mayinclude as input into the function heart rate as determined from firstmedical device data output by a first medical device (e.g., a heart ratemonitor) and body temperature as determined from second medical devicedata output by a second medical device (e.g., a temperature sensor). Theheart rate may be displayed in a first patient monitoring parameter tileon a single-patient GUI, the body temperature may be displayed in asecond patient monitoring parameter tile on the single-patient GUI, andthe notification output as a result of the function may be displayed asa third tile on the single-patient GUI, at least when the specifiedconditions trigger the notification. In this way, user-selectedfunctions may utilize medical device data, which may include medicaldevice data from two or more devices in some examples, and may also usethe results of other functions to provide insights into current orfuture patient state that may not be possible by monitoring the outputof individual medical devices in isolation. For example, a heart ratemonitor may be configured to output an alarm when heart rate is veryhigh, such as greater than 150 beats per minute. While such an alarm maybe useful, the alarm may miss earlier or more subtle signs that thepatient may be undergoing duress. Thus, a function that combines achange in heart rate with body temperature may be able to provide anearlier potential warning of sepsis or other deterioration in patientstate than by relying solely on heart rate reaching a predefinedthreshold. If the patient has a low resting heart rate, for example, therelative change in heart rate may be more informative than the absolutenumber of beats per minute, and by combining the change in heart ratewith body temperature, the change in heart rate may be put into bettercontext and thus provide different information to a care provider thanif heart rate changed while body temperature remained stable.

At 2716, a command to adjust a machine parameter is sent to anidentified therapy device if requested. For example, a determination maybe made if a request to change a machine parameter has been received. Asexplained above with respect to FIG. 24, a user of the supervisoryapplication (e.g., the supervising care provider interacting with thesupervising application on a care provider device) may request a machineparameter or setting be adjusted via an adjustment box displayed as partof the single-patient GUI. The care provider device may send a requestto the edge device to adjust the machine parameter. The therapy devicemay be identified based on the received request from the care providerdevice, which may specify which machine (e.g., therapy device) is to beadjusted and which parameter of the machine is to be adjusted (and byhow much).

At 2718, a message or consult request is sent to an identified careprovider device if requested. For example, a message or consult requestmay be received from a first care provider device (e.g., from a devicebeing used by a subordinate care provider, such as care provider device136) that is displaying the in-room GUI. If a message or consult requesthas been received, the message or consult request may be sent to anidentified care provider device. The recipient care provider device maybe identified in the message or consult request sent by the careprovider device, and the identified care provider device may be asecond, different care provider device, such a care provider devicebeing used by a supervising care provider (e.g., care provider device134). Method 2700 then returns.

In another representation, a system includes a display and a computingdevice operably coupled to the display and storing instructionsexecutable to: output, to the display, a graphical user interface (GUI)that includes real-time medical device data collected by a plurality ofmedical devices each monitoring a patient and also includes one or moremachine parameters for one or more therapy devices being utilized in amedical procedure performed on the patient; responsive to a user input,output, to the display, an action menu including one or more controlbuttons selectable to adjust a selected machine parameter of the one ormore machine parameters; and responsive to user selection of one or moreof the one or more control buttons, send a request to adjust theselected machine parameter to a therapy device associated with theselected machine parameter, the request sent via an intermediateprocessing system.

In another representation, a system includes a display and a computingdevice operably coupled to the display and storing instructionsexecutable to output, on the display, a user interface that presents toa user medical device data aggregated from multiple medical devices, theuser interface also configured to present to the user availableparameters that are based on the medical device data and availableoperators, and the user interface is configured to receive user inputspecifying a user-defined relationship for display in a tile of the userinterface, the user-defined relationship using selected ones of theavailable operators and the available parameters.

In another representation, a system includes a display and a computingdevice operably coupled to the display and storing instructionsexecutable to output, on the display, a user interface that presents toa user medical device data aggregated from multiple medical devices, theuser interface configured to present to medical device data as aplurality of patient monitoring parameter tiles, and where the userinterface is configurable by the user and presents a plurality ofuser-selectable display formats for medical device data in the pluralityof patient monitoring parameter tiles. In an example, the plurality ofuser-selectable display formats includes a first display format wherethe medical device data is presented as a most-recently determinedvalue, a second display format where the medical device data ispresented as a trend of values over a specified time duration, a thirddisplay format where the medical device data is presented as a waveform,a fourth display format where multiple related parameters of the medicaldevice data are displayed in a single tile, and combinations thereof.The multiple related parameters of the medical device data that may bedisplayed in a single tile include systolic and diastolic blood pressuredisplayed in a single tile and end tidal (Et) oxygen content andfraction of inspired air (Fi) oxygen content in a single tile.

A technical effect of a supervisory application that displays medicaldevice data aggregated from multiple medical devices on a singlegraphical user interface in a user-configurable manner is that a user,such as a care provider, may view desired patient monitoring parametersfor a patient the user is monitoring on a limited display area, with asmuch data as possible displayed on the limited display area. Thedisplaying of the medical device data from multiple medical devices onthe single graphical user interface in a user-configurable manner alsoallows the user to monitor patient status from any location and provideinstructions via the supervisory application. The user may view newmedical device data as new medical devices are coupled to the patient.The user may define functions and/or access functions defined by otherusers via the supervisory application that may transform and/or analyzethe medical device data (from multiple medical devices) to provideresults of patient status not detectable from single values of themedical device data. The functions may be created and accessed at anytime, which may allow new functions to be defined and applied as newdevices are added. Via the supervisory application, the user may locateand view desired data without having to navigate through multiple menus,which may increase user efficiency in interacting with a computingdevice.

In an embodiment, a system includes a display; and a computing deviceoperably coupled to the display and storing instructions executable to:output, to the display, a graphical user interface (GUI) that includes aplurality of trend lines each showing values for a respective patientmonitoring parameter over a first time range, the plurality of trendlines time-aligned and vertically stacked relative to each other;responsive to a first user input, adjust each of the plurality of trendlines to show values for the respective patient monitoring parameterover a second time range; and responsive to a second user input,display, on the GUI, an overlay that shows a relative change in eachpatient monitoring parameter over a specified time duration. In a firstexample of the system, the GUI is a trends GUI, and wherein theinstructions are executable to output, to the display, a single-patientGUI in response to a user request, the single-patient GUI includingreal-time medical device data determined from output of one or moremedical devices each monitoring a patient, and where at least some ofthe real-time medical device data displayed via the single-patient GUIis displayed as a plurality of patient monitoring parameter tiles, eachpatient monitoring parameter tile showing a most-recently determinedvalue for that patient monitoring parameter, and wherein the values foreach respective patient monitoring parameter for the plurality of trendlines are determined from the output of the one or more medical devices.In a second example of the system, which optionally includes the firstexample, the instructions are executable to output, to the display, aset of trends within the single-patient GUI in response to userselection of a first patient monitoring parameter tile, wherein the setof trends includes a first trend line showing values for the firstpatient monitoring parameter over the first or second time range, thevalues for the first patient monitoring parameter determined from theoutput from the one or more medical devices. In a third example of thesystem, which optionally includes one or both of the first and secondexamples, the set of trends further includes a trends icon, and whereinthe instructions are executable to output the trends GUI to the displayin response to user selection of the trends icon. In a fourth example ofthe system, which optionally includes one or more or each of the firstthrough third examples, the instructions are executable to output thetrends GUI to the display in response to user selection of a trendsbutton of a context menu, the context menu output to the display inresponse to user selection of a menu button displayed on the display aspart of the single-patient GUI. In a fifth example of the system, whichoptionally includes one or more or each of the first through fourthexamples, the instructions are executable to output a multi-patient GUIincluding real-time medical device data determined from output of aplurality of medical devices monitoring a plurality of patients, theplurality of patients including the patient and one or more additionalpatients, and wherein the instructions are executable to output thesingle-patient GUI in response to user selection of a representation ofthe patient in the multi-patient GUI. In a sixth example of the system,which optionally includes one or more or each of the first through fifthexamples, the first time range is different than the second time range,and wherein the specified time range is specified by a user.

In an embodiment, a method includes outputting, to a display, a firstgraphical user interface (GUI) that includes real-time medical devicedata determined from output of one or more medical devices eachmonitoring a patient, and where at least some of the real-time medicaldevice data displayed via the first GUI is displayed as a plurality ofpatient monitoring parameter tiles, each patient monitoring parametertile showing a most-recently determined value for that patientmonitoring parameter; and responsive to a user request, outputting, to adisplay, a second GUI that includes a plurality of trend lines eachshowing values for a respective patient monitoring parameter over afirst time range, the plurality of trend lines time-aligned andvertically stacked relative to each other. In a first example of themethod, outputting the second GUI responsive to the user requestincludes outputting the second GUI responsive to user selection of atrends icon displayed as part of the first GUI or responsive to userselection of a trends button of a context menu that is configured to bedisplayed in response to user selection of a menu button of the firstGUI. In a second example of the method, which optionally includes thefirst example, the first GUI further includes an alarm tile and aninsights tile, the alarm tile including an indication of a number ofalarms that have been triggered for the patient and the insights tileincluding an indication of a number of insights that have been triggeredfor the patient. In a third example of the method, which optionallyincludes one or both of the first and second examples, the methodfurther includes receiving an alarm for the patient in response to avalue of a specified patient monitoring parameter determined from amedical device meeting a predetermined condition relative to athreshold, and in response to user selection of the alarm tile,outputting an alarm banner in the first GUI that indicates the value ofthe specified patient monitoring parameter has met the predeterminedcondition relative to the threshold. In a fourth example of the method,which optionally includes one or more or each of the first through thirdexamples, the method further includes triggering an insight for thepatient in response to a set of values determined from the output of theone or more medical devices meeting a condition and a scope of thecondition, and in response to user selection of the insight tile,outputting an insight banner in the first GUI that indicates the set ofvalues has met the condition and the scope of the condition. In a fifthexample of the method, which optionally includes one or more or each ofthe first through fourth examples, the method further includes adjustinga layout of the first GUI in response to user input, the layout of thefirst GUI including which patient monitoring parameter tiles areincluded in the first GUI and/or a visual appearance of each patientmonitoring parameter tile of the first GUI. In a sixth example of themethod, which optionally includes one or more or each of the firstthrough fifth examples, the one or more medical devices include ananesthesia delivery machine, wherein the output of the medical devicesincludes physiological data of the patient collected by the anesthesiamachine and machine data including settings of the anesthesia deliverymachine, and wherein the plurality of trend lines of the second GUI areorganized into physiological trends and machine settings trends.

In an embodiment, a system includes a display; and a computing deviceoperably coupled to the display and storing instructions executable to:output, to the display, a graphical user interface (GUI) that includesreal-time medical device data determined from output of one or moremedical devices each monitoring a patient, and where at least some ofthe real-time medical device data displayed via the GUI is displayed asa plurality of patient monitoring parameter tiles, each patientmonitoring parameter tile showing a most-recently determined value forthat patient monitoring parameter; responsive to a user selection of afirst patient monitoring parameter tile showing a most-recentlydetermined value for a first patient monitoring parameter, adjust theGUI to include a trend display for the first patient monitoringparameter and also include one or more additional trend displays forrelated patient monitoring parameters. In a first example of the system,the related patient monitoring parameters are preselected by a user. Ina second example of the system, which optionally includes the firstexample, the trend display for the first patient monitoring parameterand the one or more additional trend displays for the related patientmonitoring parameters each include a trend line each showing a change invalues for a respective patient monitoring parameter over a timeduration. In a third example of the system, which optionally includesone or both of the first and second examples, the instructions areexecutable to overlay a timeline on the trend display for the firstpatient monitoring parameter and the one or more additional trenddisplays for the related patient monitoring parameters, the timelineincluding a respective value for the first patient monitoring parameterand each related patient monitoring parameter at a time corresponding toa position of the timeline. In a fourth example of the system, whichoptionally includes one or more or each of the first through thirdexamples, the one or more medical devices include an anesthesia deliverymachine, wherein the output of the medical devices includesphysiological data of the patient collected by the anesthesia machineand machine data including settings of the anesthesia delivery machine,and wherein the first GUI further includes a procedure timing tileincluding a current phase of anesthesia delivery to the patient. In afifth example of the system, which optionally includes one or more oreach of the first through fourth examples, the first GUI includes aplurality of categories, and each patient monitoring parameter tile isassigned to a category of the plurality of categories.

In an embodiment, a system includes a computing device storinginstructions executable to: receive an insight defined by a user, theinsight dictating that a notification be output when a condition and ascope of the condition are met, the condition and the scope defined bythe user; receive real-time medical device data determined from outputfrom a plurality of medical devices monitoring a plurality of patients;determine if a set of values of one or more patient monitoringparameters of the medical device data meet the condition and the scope,and if so, output the notification for display on a display operablycoupled to a first care provider device associated with the user; andresponsive to a request from the user, adjust a privacy setting of theinsight to allow the insight to be distributed to one or more additionalcare provider devices associated with other users. In a first example ofthe system, the insight is a first insight dictating that a firstnotification be output when a first condition and a first scope of thefirst condition are met, and wherein the instructions are furtherexecutable to: receive a first request, from the first care providerdevice, to view a plurality of second insights defined by one or moreadditional users; in response to receiving the first request, send theplurality of second insights to the first care provider device; receivea second request, from the first care provider device, to apply aselected one of the plurality of second insights, the selected one ofthe plurality of second insights dictating that a second notification beoutput when a second condition and a second scope of the secondcondition are met; and in response to the second request, determine if asecond set of values of one or more patient monitoring parameters of themedical device data meet the second condition and the second scope, andif so, output the second notification for display on the displayoperably coupled to the first care provider device. In a second exampleof the system, which optionally includes the first example, thecondition includes a selected patient monitoring parameter value ortrend meeting a predetermined relationship relative to a threshold, andwherein the scope includes a timing- or procedure-based limitation onwhen the condition being met triggers the notification. In a thirdexample of the system, which optionally includes one or both of thefirst and second examples, the insight is defined, by the user, as beingapplicable to only selected one or more patients of the plurality ofpatients. In a fourth example of the system, which optionally includesone or more or each of the first through third examples, the insight isa first insight dictating that a first notification be output when afirst condition and a first scope of the first condition are met, andwherein the instructions are further executable to: receive a request,from the first care provider device, to apply a second insight, thesecond insight dictating that a second notification be output when asecond condition and a second scope of the second condition are met anda third condition and a third scope of the third condition are all met;determine if a second set of values of one or more patient monitoringparameters the medical device data meet the second condition and thesecond scope and the third condition and the third scope, and if so,output the second notification for display on the display operablycoupled to the first care provider device. In a fifth example of thesystem, which optionally includes one or more or each of the firstthrough fourth examples, the instructions are further executable to:receive a second request, from a second care provider device of the oneor more additional care provider devices, to view the insight, and inresponse, send the insight to the second care provider device. In asixth example of the system, which optionally includes one or more oreach of the first through fifth examples, the instructions are furtherexecutable to: receive a third request, from the second care providerdevice, to apply the insight to one or more patients of the plurality ofpatients; in response to the third request, determine if a second set ofvalues of one or more patient monitoring parameters of the medicaldevice data meet the condition and the scope, and if so, output thenotification for display on a display operably coupled to the secondcare provider device. In a seventh example of the system, whichoptionally includes one or more or each of the first through sixthexamples, the instructions are further executable to: receive an alarmfrom one of the plurality of medical devices; determine if the user hasselected to receive the alarm; and if the user has selected to receivethe alarm, output an indication of the alarm for display on the displayoperably coupled to the first care provider device. In an eighth exampleof the system, which optionally includes one or more or each of thefirst through seventh examples, the alarm indicates that a value of apatient monitoring parameter of medical device data determined fromoutput of the one of the plurality of medical devices has reached apredetermined condition relative to a threshold.

An embodiment of a system includes a display; and a computing deviceoperably coupled to the display and storing instructions executable to:output, to the display, real-time medical device data, the real-timemedical device data viewable on the display in a graphical userinterface (GUI), the real-time medical device data determined fromoutput of one or more medical devices monitoring one or more patients;output, to the display, a determined result of a first user-selectedfunction, the real-time medical device data entered as input into thefirst function, the determined result of the first function viewable onthe display as a tile of the GUI; and output, to the display, anotification responsive to a second user-selected function being met,the determined result of the first function entered as input into thesecond function. In a first example of the system, the real-time medicaldevice data is also entered as input into the second function, andwherein one or both of the first function and second function areselected via a second GUI displayed on the display. In a second exampleof the system, which optionally includes the first example, one or bothof the first function and the second function are defined by a user. Ina third example of the system, which optionally includes one or both ofthe first and second examples, the second function is defined by thefirst function, a second parameter selected by the user from apredefined set of parameters, and an operator selected by the user froma predefined set of operators. In a fourth example of the system, whichoptionally includes one or more or each of the first through thirdexamples, the one or more medical devices includes an anesthesiadelivery machine, wherein the determined result of the first function isa current phase of anesthesia delivery from the anesthesia deliverymachine, wherein the predefined set of parameters includes each patientmonitoring parameter that is able to be determined from the real-timemedical device data, and wherein the predefined set of operatorsincludes one or more of and, or, and while.

In an embodiment, a system includes a first display; and a firstcomputing device operably coupled to the first display and storinginstructions executable to: output, to the first display, a firstgraphical user interface (GUI) that includes real-time medical devicedata determined from output of one or more medical devices eachmonitoring a patient; display on the first GUI a notification indicatinga request to communicate with a care provider attending to the patienthas been received; and responsive to user selection of the notification,display on the first GUI a communication from the care provider, wherethe communication from the care provider is received via a second GUIdisplayed on a second display device operably coupled to a secondcomputing device. In a first example of the system, the communicationincludes one or more of a request for a consultation, a text message, ora snapshot of the second GUI. In a second example of the system, whichoptionally includes the first example, the first GUI includes a firstplurality of patient monitoring parameter tiles each displaying arespective patient monitoring parameter, each respective patientmonitoring parameter showing a most-recently determined value and/ortrend for that patient monitoring parameter obtained from the real-timemedical device data, and wherein the notification is displayed in anotification tile on the first GUI. In a third example of the system,which optionally includes one or both of the first and second examples,the second GUI includes a second plurality of patient monitoringparameter tiles that matches the first plurality of patient monitoringparameter tiles, a call button, and a message view button. In a fourthexample of the system, which optionally includes one or more or each ofthe first through third examples, the communication from the careprovider being received via the second GUI includes the first computingdevice receiving the communication responsive to a selection, by thecare provider, of the call button of the second GUI. In a fifth exampleof the system, which optionally includes one or more or each of thefirst through fourth examples, the communication from the care providerbeing received via the second GUI includes the first computing devicereceiving the communication responsive to a selection, by the careprovider, of the message view button of the second GUI, the selection ofthe message view button causing a message box to be displayed on thesecond display via which the communication from the care provider isentered.

An embodiment for a system includes a display; and a computing deviceoperably coupled to the display and storing instructions executable to:output, to the display, a graphical user interface (GUI) that includesreal-time medical device data determined from output of one or moremedical devices each monitoring a patient, and where at least some ofthe real-time medical device data displayed via the GUI is displayed asa plurality of patient monitoring parameter tiles, each patientmonitoring parameter tile showing a most-recently determined value or atrend for that patient monitoring parameter, the plurality of patientmonitoring parameter tiles arranged according to a first layout; andresponsive to a user action, adjust one or more patient monitoringparameter tiles of the plurality of patient monitoring parameter tilesto form a second layout. In a first example of the system, adjusting theone or more patient monitoring parameter tiles of the plurality ofpatient monitoring parameter tiles to form the second layout includesmoving or resizing the one or more patient monitoring parameter tiles toform the second layout. In a second example of the system, whichoptionally includes the first example, the user action comprises arequest to switch from the first layout to the second layout, therequest entered via a context menu displayed on the display. In a thirdexample of the system, which optionally includes one or both of thefirst and second examples, the user action comprises a request toinclude a new patient monitoring parameter tile on the GUI or a requestto remove one of the plurality of patient monitoring parameter tilesfrom the GUI. In a fourth example of the system, which optionallyincludes one or more or each of the first through third examples, theuser action comprises a request to view a trend on a selected patientmonitoring parameter tile. In a fifth example of the system, whichoptionally includes one or more or each of the first through fourthexamples, adjusting the one or more patient monitoring parameter tilescomprises increasing a size of the selected patient monitoring parametertile to accommodate the trend, and also adjusting one or more additionalpatient monitoring parameter tiles to accommodate the increased size ofthe selected patient monitoring parameter tile. In a sixth example ofthe system, which optionally includes one or more or each of the firstthrough fifth examples, the user action comprises a request to arrangethe plurality of patient monitoring parameters according to one or morecategories. In a seventh example of the system, which optionallyincludes one or more or each of the first through sixth examples, theuser action comprises a request to view a result from a user-selectedfunction as a tile on the GUI. In an eighth example of the system, whichoptionally includes one or more or each of the first through seventhexamples, the real-time medical device data is applied as input to theuser-selected function. In a ninth example of the system, whichoptionally includes one or more or each of the first through eighthexamples, the GUI is a single-patient GUI, and wherein instructions areexecutable to output a multi-patient GUI including real-time medicaldevice data determined from output of a plurality of medical devicesmonitoring a plurality of patients, the plurality of patients includingthe patient and one or more additional patients, and wherein theinstructions are executable to output the single-patient GUI in responseto user selection of a representation of the patient in themulti-patient GUI.

An embodiment for a method includes displaying real-time medical devicedata determined from output of one or more medical devices eachmonitoring a patient via a plurality of patient monitoring parametertiles of a graphical user interface (GUI) arranged to form a firstlayout; receiving a request to apply a user-selected function, theuser-selected function configured to generate a result based on thereal-time medical device data; in response to the request, displayingthe result of the user-selected function in a function tile on the GUIand automatically adjusting one or more patient monitoring parametertiles of the plurality of patient monitoring parameter tiles to form asecond layout. In a first example of the method, automatically adjustingthe one or more patient monitoring parameter tiles comprisesautomatically moving and/or resizing the one or more patient monitoringparameter tiles to accommodate the function tile. In a second example ofthe method, which optionally includes the first example, theuser-selected function is defined by the user and the request to applythe user-selected function is received via input from the user. In athird example of the method, which optionally includes one or both ofthe first and second examples, the user-selected function is a firstfunction, and wherein receiving the request to apply the first functioncomprises displaying an indication of the first function and a pluralityof additional indications of additional functions and receiving userinput from the user requesting to apply the first function, where thefirst function and the plurality of additional functions are defined byone or more other users. In a fourth example of the method, whichoptionally includes one or more or each of the first through thirdexamples, the method further includes, responsive to a user action,further adjusting one or more patient monitoring parameter tiles of theplurality of patient monitoring parameter tiles to form a third layout.

An embodiment for a method includes displaying real-time medical devicedata determined from output of one or more medical devices eachmonitoring a patient via a plurality of patient monitoring parametertiles of a graphical user interface (GUI) arranged to form a firstlayout, including displaying first medical device data determined fromoutput of a first medical device in a first patient monitoring parametertile and displaying second medical device data determined from output ofa second medical device in a second patient monitoring parameter tile;receiving a request to apply a user-selected function, the user-selectedfunction configured to generate a result based on the first medicaldevice data displayed in the first patient monitoring parameter tile andthe second medical device data displayed in the second patientmonitoring parameter tile; and in response to the request, displayingthe result of the user-selected function in a function tile on the GUIand automatically adjusting one or more patient monitoring parametertiles of the plurality of patient monitoring parameter tiles to form asecond layout. In a first example of the method, the result includes oneof a determination of current patient status, a prediction of futurepatient status, and a determination of a current phase a medicalprocedure being performed on the patient. In a second example of themethod, which optionally includes the first example, the method furtherincludes receiving an alarm from the first medical device indicatingthat a value the first medical device data has reached a predeterminedcondition relative to a threshold, and in response, displaying anotification of the alarm in an alarm tile of the GUI. In a thirdexample of the method, which optionally includes one or both of thefirst and second examples, automatically adjusting the one or morepatient monitoring parameter tiles comprises automatically moving and/orresizing the one or more patient monitoring parameter tiles toaccommodate the function tile. In a fourth example of the method, whichoptionally includes one or more or each of the first through thirdexamples, the method further includes, responsive to a user action,further adjusting one or more patient monitoring parameter tiles of theplurality of patient monitoring parameter tiles to form a third layout.

As used herein, an element or step recited in the singular and proceededwith the word “a” or “an” should be understood as not excluding pluralof said elements or steps, unless such exclusion is explicitly stated.Furthermore, references to “one embodiment” of the present invention arenot intended to be interpreted as excluding the existence of additionalembodiments that also incorporate the recited features. Moreover, unlessexplicitly stated to the contrary, embodiments “comprising,”“including,” or “having” an element or a plurality of elements having aparticular property may include additional such elements not having thatproperty. The terms “including” and “in which” are used as theplain-language equivalents of the respective terms “comprising” and“wherein.” Moreover, the terms “first,” “second,” and “third,” etc. areused merely as labels, and are not intended to impose numericalrequirements or a particular positional order on their objects.

This written description uses examples to disclose the invention,including the best mode, and also to enable a person of ordinary skillin the relevant art to practice the invention, including making andusing any devices or systems and performing any incorporated methods.The patentable scope of the invention is defined by the claims, and mayinclude other examples that occur to those of ordinary skill in the art.Such other examples are intended to be within the scope of the claims ifthey have structural elements that do not differ from the literallanguage of the claims, or if they include equivalent structuralelements with insubstantial differences from the literal languages ofthe claims.

1. A system, comprising: a display; and a computing device operablycoupled to the display and storing instructions executable to: output,to the display, a multi-patient graphical user interface (GUI) includingreal-time medical device data determined from output of a plurality ofmedical devices monitoring a plurality of patients; in response to userselection of a representation of a patient of the plurality of patientsin the multi-patient GUI, output, to the display, a single-patient GUIthat includes real-time medical device data determined from output ofone or more medical devices each monitoring the patient, and where atleast some of the real-time medical device data displayed via thesingle-patient GUI is displayed as a plurality of patient monitoringparameter tiles, each patient monitoring parameter tile showing amost-recently determined value or a trend for that patient monitoringparameter, the plurality of patient monitoring parameter tiles arrangedaccording to a first layout; responsive to a user action, automaticallyadjust one or more patient monitoring parameter tiles of the pluralityof patient monitoring parameter tiles to form a second layout; andoutput, to the display, the single-patient GUI including the pluralityof patient monitoring parameter tiles displayed in the second layout. 2.The system of claim 1, wherein adjusting the one or more patientmonitoring parameter tiles of the plurality of patient monitoringparameter tiles to form the second layout includes moving or resizingthe one or more patient monitoring parameter tiles to form the secondlayout.
 3. The system of claim 1, wherein the user action comprises arequest to switch from the first layout to the second layout, therequest entered via a context menu displayed on the display.
 4. Thesystem of claim 1, wherein the user action comprises a request toinclude a new patient monitoring parameter tile on the single-patientGUI or a request to remove one of the plurality of patient monitoringparameter tiles from the single-patient GUI.
 5. The system of claim 1,wherein the user action comprises a request to view a trend on aselected patient monitoring parameter tile.
 6. The system of claim 5,wherein adjusting the one or more patient monitoring parameter tilescomprises increasing a size of the selected patient monitoring parametertile to accommodate the trend, and also adjusting one or more additionalpatient monitoring parameter tiles to accommodate the increased size ofthe selected patient monitoring parameter tile.
 7. The system of claim1, wherein the user action comprises a request to arrange the pluralityof patient monitoring parameters according to one or more categories. 8.The system of claim 1, wherein the user action comprises a request toview a result from a user-selected function as a tile on thesingle-patient GUI.
 9. The system of claim 8, wherein the real-timemedical device data is applied as input to the user-selected function.10. A method executable by a computing device operably coupled to adisplay, comprising: displaying, on the display a plurality of patientmonitoring parameter tiles of a graphical user interface (GUI) arranged,by the computing device, to form a first layout, the plurality ofpatient monitoring parameter tiles depicting real-time medical devicedata determined from output of one or more medical devices eachmonitoring a patient; receiving a request to apply a user-selectedfunction, the user-selected function applied, by the computing device,to the real-time medical device data in order to generate a result; inresponse to the request, displaying, on the display, the result of theuser-selected function in a function tile on the GUI; and automaticallyadjusting, via the computing device, one or more patient monitoringparameter tiles of the plurality of patient monitoring parameter tilesto form a second layout to accommodate the function tile, the GUI withthe function tile and the plurality of patient monitoring parametertiles in the second layout displayed on the display.
 11. The method ofclaim 10, wherein automatically adjusting the one or more patientmonitoring parameter tiles comprises automatically moving and/orresizing the one or more patient monitoring parameter tiles toaccommodate the function tile.
 12. The method of claim 10, wherein theuser-selected function is defined by the user and the request to applythe user-selected function is received via input from the user.
 13. Themethod of claim 10, wherein the user-selected function is a firstfunction, and wherein receiving the request to apply the first functioncomprises displaying an indication of the first function and a pluralityof additional indications of additional functions and receiving userinput from the user requesting to apply the first function, where thefirst function and the plurality of additional functions are defined byone or more other users.
 14. The method of claim 10, further comprising,responsive to a user action, further adjusting one or more patientmonitoring parameter tiles of the plurality of patient monitoringparameter tiles to form a third layout.
 15. A method executable by acomputing device operably coupled to a display, comprising: displaying,on the display, real-time medical device data determined from output ofone or more medical devices each monitoring a patient via a plurality ofpatient monitoring parameter tiles of a graphical user interface (GUI)arranged, via the computing device, to form a first layout, includingdisplaying first medical device data determined from output of a firstmedical device in a first patient monitoring parameter tile anddisplaying second medical device data determined from output of a secondmedical device in a second patient monitoring parameter tile; receivinga request to apply a user-selected function, the user-selected functionconfigured to generate a result based on the first medical device datadisplayed in the first patient monitoring parameter tile and the secondmedical device data displayed in the second patient monitoring parametertile; and in response to the request, displaying, on the display, theresult of the user-selected function in a function tile on the GUI andautomatically adjusting, via the computing device, one or more patientmonitoring parameter tiles of the plurality of patient monitoringparameter tiles to form a second layout, the GUI with the function tileand the plurality of patient monitoring parameter tiles including thefirst patient monitoring parameter tile and the second patientmonitoring parameter tile in the second layout displayed on the display.16. The method of claim 15, wherein the result includes a determinationof current patient status.
 17. The method of claim 15, wherein theresult includes a prediction of future patient status, and furthercomprising receiving an alarm from the first medical device indicatingthat a value the first medical device data has reached a predeterminedcondition relative to a threshold, and in response, displaying anotification of the alarm in an alarm tile of the GUI.
 18. The method ofclaim 15, wherein the result includes a determination of a current phaseof a medical procedure being performed on the patient, and whereinautomatically adjusting the one or more patient monitoring parametertiles comprises automatically moving and/or resizing the one or morepatient monitoring parameter tiles to accommodate the function tile. 19.The method of claim 15, further comprising, responsive to a user action,further adjusting one or more patient monitoring parameter tiles of theplurality of patient monitoring parameter tiles to form a third layout.